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Kurzfassung 


Kundenindividuelle Produkte werden in vielen Märkten immer stärker nach- 
gefragt und stellen Unternehmen vor die Herausforderung, diese in möglichst 
vielen Varianten und dennoch effizient herstellen zu können. Ein möglicher 
Ansatz dazu ist die kollaborative Montage, die die besonderen Fähigkeiten 
von Mensch und Roboter kombiniert. Neben Fragen der Sicherheit und der 
physischen Gestaltung des Arbeitsplatzes kommt dem Informationsmanage- 
ment eine besondere Rolle zu, denn im Vergleich zur rein manuellen oder 
vollautomatisierten Montage gibt es mehr Beteiligte, mehr Schnittstellen und 


daher auch mehr kritische Informationsflüsse. 


Ein kollaborationsgerechtes Wissens- und Prozessmanagement muss die 
Integration aller beteiligten Systeme unterstützen, spezifische Fragen der Ar- 
beitsteilung im Rahmen der Steuerung adressieren, aber auch die Planung und 
das Engineering neuer Varianten ermöglichen und durch Persistierung und 


Analyse von Prozessdaten zu einer stetigen Qualitätssteigerung beitragen. 


Ziel der vorliegenden Arbeit ist die Entwicklung und Validierung einer ent- 
sprechenden Methodik. Dazu wird das Konzept eines „Manufacturing In- 
tegration Bus“ eingeführt und mit speziellen Verfahren zur kollaborativen 
Arbeitssteuerung und einem durchgehenden Ansatz zur Verwertung der Pro- 


zessdaten kombiniert. 


An einem Minimal-Demonstrator, einem Demonstrator mit erweiterten Fä- 


higkeiten und einer industriellen Anlage wird die Methodik validiert. 


Abstract 


Customer-specific products are increasingly in demand in many markets and 
present companies with the challenge of being able to manufacture them in 
as many variants as possible and still efficiently. One possible approach is 
collaborative assembly, which combines the special capabilities of humans 
and robots. In addition to questions of safety and the physical design of the 
workplace, information management plays a crucial role, because compared 
to purely manual or fully automated assembly, there are more participants, 


more interfaces and therefore more critical information flows. 


Collaboration-oriented knowledge and process management must support 
the integration of all systems involved, address specific questions of the 
division of labor within the control system, but also enable the planning and 
engineering of new variants and contribute to a continuous increase in quality 


through the persistence and analysis of process data. 


The aim of this thesis is the development and validation of a corresponding 
methodology. The concept of a „Manufacturing Integration Bus“ is introdu- 
ced and combined with special procedures for collaborative work control and 


a continuous approach for the utilization of the process data. 


The methodology will be validated using a minimum demonstrator, a de- 


monstrator with extended capabilities and an industrial machine. 
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1 Einleitung 


In diesem einführenden Kapitel wird zunächst die Motivation dargelegt, eine 
Methodik für das Informationsmanagement bei der interaktiven kollaborati- 
ven Montage variantenreicher Produkte zu etablieren (Abschnitt 1.1). Darauf 
aufbauend wird im folgenden Abschnitt 1.2 die Ausgangssituation beschrie- 
ben und die zentrale Problemstellung formuliert, die dann in Abschnitt 1.3 
zur Zielsetzung der vorliegenden Arbeit führt. Diese wird durch mehrere 
Forschungsfragen weiter präzisiert und in den weiteren Hauptkapiteln häufig 
referenziert. Der letzte einleitende Abschnitt 1.4 gibt einen Überblick über 
den Aufbau der Arbeit. 


1.1 Motivation 


Zwischen der seit etlichen Jahrzehnten etablierten Massenproduktion von 
Gütern und der noch länger existierenden vollständig kundenindividuellen 
Herstellung einer Ware bildet sich in den letzten Jahren eine Produktions- 
weise aus, die die beiden Vorzüge der vorgenannten traditionellen Wege zu 
vereinen sucht. Der sich in Richtung individueller Lösungen entwickelnden 
Nachfrage soll ein effizientes Angebot basierend auf modularen Systemen 
entgegenkommen, das die Herstellung individueller Produktvarianten (na- 
hezu) zum Preis eines Massenprodukts ermöglicht. Dazu gestalten viele 
produzierende Unternehmen ihre Produkte als Baukastensystem, das aus in 


großen Stückzahlen hergestellten einzelnen Modulen besteht, die erst in der 


1 Einleitung 


Montage aufgrund der zahlreichen daraus herstellbaren Varianten des End- 
produkts ein individuelles Produkt bilden. In den Produktionsschritten vor 
der Montage nutzen die Unternehmen den hohen Wiederverwendungsgrad 
und die Möglichkeiten zur Standardisierung der Komponenten (Kluge 2011). 
Zur Montage der unterschiedlichen Varianten solcher Produkte kommt es 
auf die Flexibilität und Wandelbarkeit der Montagesysteme und -prozesse an, 
insbesondere auch vor dem Hintergrund der angestrebten Wirtschaftlichkeit 
(Steinbauer 2012). Die Lücke zwischen der flexiblen und mit relativ geringen 
Investitionen verbundenen durch Arbeiter durchgeführten Montage und einer 
nur bei großen Stückzahlen wirtschaftlich attraktiven Vollautomatisierung 
kann die kollaborative Montage, bei der Mensch und Roboter gemeinsam ein 
Produkt montieren, zumindest teilweise schließen. Dabei können die beson- 
deren Fähigkeiten des Roboters wie Kraft oder Präzision mit der Flexibilität 


und fehlertoleranten Arbeitsweise des Menschen kombiniert werden. 


Neben zahlreichen weiteren Fragen wie zum Beispiel der Auswahl des Ro- 
botertyps für kollaborative Montage, der Aus- und Weiterbildung der Mitar- 
beiter oder auch der Berücksichtigung von Sicherheitsaspekten kommt dem 
Informationsmanagement eine Schlüsselrolle beim Einsatz kollaborativer 
Montagesysteme zu, denn sie tragen zu Effizienz und damit Wirtschaftlich- 
keit der Rekonfiguration wesentlich bei. Dabei kommt es einerseits auf die 
adäquate Bereitstellung aller erforderlichen Betriebsdaten insbesondere zur 
Steuerung der Montageprozesse innerhalb der kollaborativen Zelle an. Ande- 
rerseits müssen die bei der tatsächlichen Montage gewonnenen Prozessdaten 
persistiert und aggregiert für den nächsten Engineering-Zyklus zur Verfügung 
gestellt werden, damit sie als Basis einer kontinuierlichen Optimierung die- 
nen können. Diese Aspekte sind bei der kollaborativen Montage von weitaus 


größerer Bedeutung als bei der konventionellen Montage. 


Die wichtigsten Aspekte und Fragestellungen zur Motivation eines integrier- 


ten kollaborationsgerechten Informationsmanagements sind schlagwortar- 


tig: 


1.1 Motivation 


e Flexible kollaborative Montage 

e Re-Engineering und Konfiguration 

e Anpassung an neue Varianten 

e Aufgabenteilung zwischen Mensch und Roboter 


e Wirtschaftlichkeit 


Ein integrierter Ansatz fiir das Wissens- und Prozessmanagement zur Ge- 
währleistung einer effizienten kollaborativen Montage muss dabei einerseits 
die Produktentstehung unterstützen und andererseits die Steuerung und Or- 
ganisation der Montageprozesse selbst umfassen. Dabei kommen mehrere 
Zeitebenen von der langfristig orientierten Planung über die kurzfristige 
Steuerung einzelner Arbeitsschritte bis hin zur Echtzeit-Interaktion in Frage. 
Gleichzeitig sind der Übergang von der klassischen Automatisierungspyrami- 
de zu einer umfassenderen und flexibleren Gestaltung der Informationsflüsse 
im Sinne des Referenzarchitekturmodells 4.0 und die Verwendung aktueller 
Standards wie OPC UA zu berücksichtigen. Obwohl bereits einige Ansätze 
für die Planung kollaborativer Prozesse (Dumonteil u. a. 2015) und Methoden 
virtueller Erprobung (R. Stark, Kind und Neumeyer 2017) existieren, gibt es 
derzeit noch keinen umfassenden Ansatz für ein konsolidiertes Informations- 


management bei der kollaborativen Montage variantenreicher Produkte. 


Die vorliegende Arbeit soll diese Lücke mit einer Methodik zum Wissens- 
und Prozessmanagement bei der interaktiven kollaborativen Montage va- 
riantenreicher Produkte schließen. Dazu wird eine Kombination mehrerer 
Methoden entwickelt und vorgestellt, die die Integration aller in diesem Kon- 
text benötigten Informationen ermöglicht und auf aktuellen Paradigmen und 
Standards basiert. 
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1.2 Ausgangssituation und Problemstellung 


Die Fähigkeit, auf sich wandelnde Anforderungen und Märkte reagieren 
zu können, ist für produzierende Unternehmen essenziell (Warnecke 1996). 
Eine von vielen Möglichkeiten diese auszubauen ist die Einbeziehung der 
kollaborativen Montage variantenreicher Produkte in dafür geeigneten Fällen. 
Unterstützt werden kann sie durch die Anwendung von Produktlebenszy- 
klusmanagementansätzen (PLM), die auch die Wirtschaftlichkeit flexibler 
Montageplätze steigern (Eigner und Stelzer 2009). Einzelne Komponenten 
oder integrierte Ansätze von PLM kommen in fast allen produzierenden Un- 
ternehmen zum Einsatz, jedoch existieren nur wenige anwendbare Ansätze 
für den Bereich der kollaborativen Montage, die an ein PLM-Konzept er- 
weiterte spezielle Anforderungen stellt. Da es sich gemäß den Liebensteiner 
Thesen (siehe auch Abschnitt 4.1) nicht um eine Lösung, sondern um ein 
„unternehmensspezifisches Konzept“ handelt, kann es einerseits auch keine 
einheitliche Lösung für die kollaborative Montage variantenreicher Produkte 
geben. Andererseits ist es dennoch möglich, übergeordnete und in vielen 
Fällen auftretende Anforderungen zu identifizieren, die dann im Einzelfall 


geprüft und angepasst werden müssen. 


In Anlehnung an die VDI Richtlinie 2860 lässt sich der Begriff ,,Kollaborative 


Montage“ wie folgt definieren: 


Kollaborative Montage ist die Gesamtheit aller Vorgänge für 
den Zusammenbau von Körpern mit geometrisch bestimmter 
Form durch mindestens einen Roboter und mindestens einen 


Menschen in einem gemeinsamen Arbeitsraum. 


Durch Einbeziehung weiterer Kriterien, insbesondere gemeinsam genutzter 


Ressourcen wie Zeit und Raum, kann die Art der Kollaboration präzisiert 


1.2 Ausgangssituation und Problemstellung 


werden (siehe auch Unterabschnitt 2.2.1). Insbesondere zur Montage vari- 
antenreicher Produkte und Produktfamilien kann die kollaborative Montage 


einen Beitrag zur Erhöhung der Wirtschaftlichkeit leisten. 


Varianten sind technische Systeme mit einem in der Regel 
hohen Anteil identischer Komponenten, die Ähnlichkeiten in 
Bezug auf Geometrie, Material oder Technologie aufweisen. 
Varianten unterscheiden sich voneinander in mindestens einer 
Beziehung oder einem Element. Unterschiede existieren bezüg- 
lich der Ausprägungen mindestens eines Merkmals (Ponn und 
Lindemann 2008). 


Ein typisches Beispiel für ein aus einzelnen kombinierbaren Modulen be- 
stehendes Produkt, das dadurch auf Basis relativ weniger Komponenten 
in zahlreichen Varianten erhältlich ist, ist die Multifunctional Gate Box 2 
(MGB2) der Euchner AG (siehe auch Abbildung 1.1). Es handelt sich dabei 
um ein Verriegelungs- oder Zuhaltungssystem zur Absicherung von Schutz- 
türen an Maschinen und Anlagen, das aus mehreren Modulen individuell 
zusammengestellt werden kann. Dabei ist das Zuhaltemodul selbst auch 
wiederum aus einzelnen Submodulen (mit Bedien- und Anzeigeelementen) 
kombinierbar, die nach Kundenwunsch montiert werden. Die Montage dieser 
Submodule dient auch als Grundlage der Fallstudie im Rahmen der Validie- 
rung in Abschnitt 5.4. 


Die Vorgehensweise zur Montage jeder einzelnen Variante muss unter ver- 
schiedenen Aspekten wie zum Beispiel Machbarkeit und Sicherheit geprüft 
werden. Daher ist es sinnvoll die Methoden des Virtual Engineering, ins- 
besondere zur Verlagerung von Ressourcen und Validierungsverfahren in 
den frühen Phasen der Entwicklung zum Einsatz zu bringen. Damit wird 
die Entwicklungszeit einer einzelnen Variante verkürzt und dadurch die Fle- 
xibilität erhöht. Wenn es gelingt, die bei der Montage anderer Varianten 


entstandenen Prozessdaten geeignet auszuwerten und in das Engineering 
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Abbildung 1.1: Multifunctional Gate Box 2 (MGB2) der Fa. Euchner als Beispiel für ein modula- 
res variantenreiches Produkt. Quelle: https: //www.euchner..de/de-de/pr 
odukte/multifunctional-gate-box-mgb2/ (abgerufen am 16.09.2019). 


einer neuen Variante einfließen zu lassen, verringert sich somit auch das Kos- 
tenrisiko in späteren Phasen der Produktentstehung (siehe auch Abbildung 
1.2). Bei klassischer Vorgehensweise hingegen wäre das Risiko höher, bei 
einem späteren Schritt in der Produktentstehung auf Probleme zu stoßen, was 


im ungünstigsten Fall jede neue Variante betreffen könnte. 


Im Laufe der Produktentstehung wird also hauptsächlich an den digitalen 
Modellen von Produkt und Anlage gearbeitet, die jeweils aus verschiedenen 
Konstruktionsdaten, Beschreibungen der Funktionalität oder Anleitungen zur 
Montage bestehen. So entsteht ein Digitaler Zwilling des Produkts und der 
Anlage selbst, der im Fall des Produkts für eine Klasse von Objekten steht, 
die im Moment der Herstellung instanziiert wird (siehe auch Abbildung 1.3). 
Diese einzelnen Instanzen erhalten weitere Eigenschaften wie zum Beispiel 
eine Seriennummer oder Prüfdaten. Auch der Digitale Zwilling der Produkti- 
onsanlage wird zum Zeitpunkt der Montage mit weiteren Daten angereichert, 


insbesondere Prozessdaten, die während der Montage erfasst werden. 


1.2 Ausgangssituation und Problemstellung 
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Abbildung 1.2: Verlagerung von Ressourcen und Validierungsverfahren in die frühen Phasen 
der Entwicklung. Verändert nach Ovtcharova (2010) 
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Abbildung 1.3: Beziehung zwischen den Lebenszyklen von Produkt und Produktionsanlage 
(Herfs, Storms, Roggendorf, Petrovic, Schubert, Schneider, Erkayhan, Rückert, 
Tracht und Heinen 2019, S. 55). Vergrößerung in Abbildung A.1 auf Seite 154. 


Aufgrund der Vielzahl an entstehenden und nutzbaren Daten ist ein dedi- 
ziertes Informationsmanagement für die kollaborative Montage erforderlich, 
das einerseits die Planung und die Steuerung der Montage unterstützt und 
andererseits die während oder nach der Montage gewonnenen Daten adäquat 


für spätere Planungszyklen zur Verfügung stellt, also alle in Abbildung 1.3 
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dargestellten Stationen umfasst. Daraus kann die folgende Problemstellung 


abgeleitet werden: 


Problemstellung der Arbeit 
Es ist ein an die kollaborative Montage variantenreicher Produk- 
te angepasstes Informationsmanagement erforderlich, um diese 


-insbesondere unter wirtschaftlichen Aspekten- zu ermöglichen. 


Einzelne Aspekte dieses Problems sind dabei: 
die Integration aller beteiligten Systeme und Prozesse 
e der Umgang mit den Digitalen Zwillingen 
e die Steuerung der kollaborativen Montage 
die Persistierung der Prozessdaten 
e das Monitoring und die Analyse der Prozessdaten 


In Abbildung 1.4 ist beispielhaft ein kollaborativer Arbeitsplatz dargestellt. 
Der Werker im Vordergrund arbeitet zeitgleich mit einem Leichtbauroboter 
im selben Arbeitsraum. Neben weiteren Werkzeugen ist auch das Terminal 


erkennbar, über das die Interaktion gesteuert werden kann. 


Die Anforderungen, die sich aus dieser Problemstellung an ein Informati- 
onsmanagement für die kollaborative Montage variantenreicher Produkte 
ergeben, werden im folgenden Abschnitt 1.3 als Ziele dieser Arbeit definiert 
und in Form von Forschungsfragen formuliert. In ihrer Gesamtheit lösen die 


Antworten darauf das oben genannte Problem. 


1.3 Zielsetzung der Arbeit 


Abbildung 1.4: Beispiel für einen kollaborativen Arbeitsplatz. Quelle: Bremer Institut für 
Strukturmechanik und Produktionsanlagen (BIME). 


1.3 Zielsetzung der Arbeit 


Im vorhergehenden Kapitel konnte der Bedarf für ein die kollaborative Mon- 
tage variantenreicher Produkte unterstützendes Informationsmanagement 
gezeigt werden. Zwar gibt es zahlreiche etablierte Ansätze für das Wissens- 
und Prozessmanagement bei der traditionellen und automatisierten Monta- 
ge, eine auf die besonderen Herausforderungen der kollaborativen Montage 
zugeschnittene Methodik jedoch noch nicht. Insbesondere die sich nur bei 
der kollaborativen Montage ergebenden Fragen wie zum Beispiel die nach 
der geeigneten Steuerung der kollaborativen Zelle oder der Aufteilung des 


Arbeitsplans zwischen Mensch und Roboter sind bisher noch offen. 


Aus diesen Überlegungen ergibt sich die dieser Arbeit zu Grunde liegende 


Hauptforschungsfrage 


F0: Wie kann ein integriertes Informationsmanagement die kol- 


laborative Montage und deren stetige Anpassung an die wech- 
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selnden Anforderungen verschiedener Varianten eines Produkts 


unterstützen? 


Daraus können wiederum einzelne Teilforschungsfragen abgeleitet werden, 
die einzelne Aspekte der Hauptforschungsfrage F0 adressieren und deren Be- 
antwortung in Gesamtheit auch die Beantwortung der Hauptforschungsfrage 
FO erlaubt. 


An der kollaborativen Montage variantenreicher Produkte sind im Allgemei- 
nen zahlreiche Systeme beteiligt, die jeweils eigene Anforderungen bezüglich 
ihrer Steuerung und Kontrolle, aber auch bezüglich der bei ihrer Aktivität 
entstehenden Prozessdaten mit sich bringen. Die in dieser Landschaft er- 
forderlichen Informationsflüsse müssen integriert und den jeweils anderen 
Komponenten zugänglich gemacht werden. Die erste Teilforschungsfrage 


lautet also: 


F1: Wie können die Informationsflüsse der verschiedenen be- 
teiligten Komponenten eines kollaborativen Montagesystems 


integriert werden? 


Bei der Montage variantenreicher Produkte erhöht sich die Komplexität der 
Anlagen, was den klassischen Ansatz zur Planung und Architektur dieser 
Systeme an seine Grenzen bringen kann (R. Stark, Kind und Neumeyer 2017). 
Ein möglicher Ansatz zur Überwindung dieser Begrenzungen sind cyber- 
physische Systeme, deren digitale Komponente eine einfachere Anpassung 
an veränderte Produktanforderungen ermöglicht. Es stellt sich daher die 


Frage: 


F2: Wie kann ein virtuelles digitales Abbild der physischen 
Komponenten der kollaborativen Montagezelle zur Verbesse- 


rung der Sicherheit und Effizienz der Montage genutzt werden? 


1.3 Zielsetzung der Arbeit 


Aber nicht nur bei der Planung und Inbetriebnahme, sondern auch bei der 
Steuerung der Montage in einer kollaborativen Zelle stellen sich neuartige 
Fragen, insbesondere wenn es um das Problem geht, welcher Arbeitsschritt 
vom Roboter und welcher vom Werker übernommen werden kann oder 
muss und welche nur gemeinsam bewältigt werden können. Ein klassischer 
Automatisierungsansatz ist hier nicht ausreichend und würde die besonderen 
Möglichkeiten der Kollaboration vernachlässigen, die Flexibilität bei der 


Aufteilung bringen und brauchen. Dies adressiert die Teilforschungsfrage: 


F3: Wie können bei der Steuerung der Montagezelle die be- 
sonderen Aspekte der kollaborativen Montage berücksichtigt 


werden? 


Die bis zu dieser Stelle berücksichtigten Fragestellungen bezogen sich auf 
Phasen des Produktentstehungsprozesses, die vor Beginn der eigentlichen 
Montage liegen. Während der Montage entstehen durch die Steuerung und 
deren Ablauf, aber auch durch verschiedene Sensoren und Messgeräte Pro- 
zessdaten, die in verschiedener Weise zur Optimierung des Montageprozesses 
selbst genutzt werden können und sollten. Dazu sind moderne Verfahren not- 
wendig, diese Daten zu aggregieren, zu persistieren und für weitere Schritte 


zur Verfügung zu stellen. Daher lautet eine weitere Teilforschungsfrage: 


F4: Wie können die bei der kollaborativen Montage entstehen- 
den Prozessdaten persistiert und zur weiteren Nutzung bereitge- 


stellt werden? 


Aus den Prozessdaten können Schlüsse zur weiteren Optimierung der Monta- 
geprozesse gezogen werden, indem diese adäquat ausgewertet werden. Dies 


kann grundsätzlich auf mindestens zwei zeitlichen Horizonten geschehen: 


e während der Montage mit dem Ziel der Beeinflussung des weiteren 


Verlaufs der Montage und 
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e nach der Montage zur Optimierung späterer Montageprozesse. 


Im ersten Fall spricht man von Monitoring, im zweiten Fall soll hier von 
Analyse die Rede sein. Da der zweite Fall im Gegensatz zum ersten nicht zeit- 
kritisch ist, stehen hier auch umfassendere und zeitaufwändigere Methoden 


zur Verfügung. Zum ersten Fall stellt sich daher die Frage: 


F5: Wie können die Prozessdaten während der kollaborativen 


Montage überwacht werden? 


Im zweiten Fall (Analyse) sollen die Ergebnisse in spätere Engineering- 
Prozesse, zum Beispiel anderer Varianten des selben Produkts, einfließen. Es 
ergibt sich also ein Zyklus zwischen tatsächlicher Montage und Engineering, 
der vielfach durchlaufen werden kann. Im Hinblick auf die Auswertung be- 


obachteter Prozessdaten ergibt sich daraus die letzte Teilforschungsfrage: 


F6: Wie kann die Analyse der Prozessdaten im Engineering- 


Prozess neuer Produktvarianten berücksichtigt werden? 


Die meisten dieser Fragestellungen bewegen sich im interdisziplinären Be- 
reich zwischen Maschinenbau und Informatik, aber auch betriebswirtschaftli- 
che und arbeitsrechtliche Überlegungen spielen eine Rolle. Ziel dieser Arbeit 
ist vor diesem Hintergrund die Entwicklung einer Methodik zum Informati- 
onsmanagement, die alle oben erläuterten Fragestellungen umfasst und damit 
auf der Informationsebene die Möglichkeiten der kollaborativen Montage 


ermöglicht oder unterstützt. 


1.4 Aufbau der Arbeit 


Der auch in Abbildung 1.5 dargestellte Aufbau der Arbeit folgt der zur Beant- 


wortung der Forschungsfragen (siehe oben) erforderlichen Vorgehensweise. 


1.4 Aufbau der Arbeit 


In diesem einleitenden Kapitel wurde die Motivation skizziert und die Aus- 
gangssituation und Problemstellung dargestellt. Auf dieser Basis wurden 
die Hauptforschungsfrage FO und die Teilforschungsfragen F1 bis F6 zur 


Umschreibung der Zielsetzung formuliert. 


Im folgenden Kapitel 2 werden einige Grundlagen des Themengebiets 
dargestellt, zentrale Begriffe definiert und aktuelle Standards, die ebenfalls 


eine Basis der Methodik darstellen, zusammenfassend erläutert. 


Das Kapitel 3 zum Stand der Wissenschaft und Technik fasst bisherige 
Untersuchungen auf dem Gebiet des Informationsmanagements und zur 
kollaborativen Montage zusammen und enthält auch ein Unterkapitel zum 


Stand der Technik in der Industrie. 


Das Kapitel 4 ist von zentraler Bedeutung und stellt die verschiedenen Teilbe- 
reiche der Methodik entsprechend den oben formulierten Forschungsfragen 
dar. Die Anforderungen an die Methodik werden entwickelt und anschlie- 
Bend die einzelnen Komponenten der Gesamtmethodik in den Unterkapiteln 


vorgestellt. 


Die Validierung der zuvor dargelegten Methodik ist Gegenstand des Kapitels 
5. Nach der Vorstellung und Erläuterung des zur Validierung verwendeten 
Ansatzes wird die im Rahmen dieser Arbeit entwickelte Methodik in drei 
Bereichen validiert: an einem Minimal-Demonstrator, an einem Demonstra- 
tor mit erweitertem Funktionsumfang und an einer industriellen Anlage in 
Inbetriebnahme. Dabei rücken jeweils bestimmte unterschiedliche Aspekte 
und Teilbereiche der gesamten Methodik in den drei verschiedenen Szenarien 


in den Fokus. 


Abschließend fasst das Kapitel 6 als Schlussbetrachtung die zentralen As- 
pekte der vorigen Kapitel zusammen, anschließend werden in einem Ausblick 


mögliche zukünftige Entwicklungen und Forschungsthemen besprochen. 


1 Einleitung 


1. Einleitung 


.1. Motivation 

. Ausgangssituation und Problemstellung 
.3. Zielsetzung der Arbeit 

. Aufbau der Arbeit 


2. Grundlagen und Begriffsdefinitionen 


. Definitionen und Umfeld 
. Mensch-Roboter-Interaktion 

.3. Montage variantenreicher Produkte 
. Grundlegende Standards 


3. Stand der Wissenschaft und Technik 
3.1. Stand der Forschung 
3.2. Stand der Technik in der Industrie 


4. Methodik für das Informationsmanagement 


. Entwicklung der Anforderungen 

. Manufacturing Integration Bus 

. Produkt- und Anlagen-Lebenszyklus 

. Digitaler Zwilling 

. Steuerung der kollaborativen Zelle 

. Persistierung von Prozessdaten 

. Monitoring und Analyse kollaborativer Prozesse 


4.1 
4.2 
4.3 
4.4 
4.5 
4.6 
4.7 


5. Validierung 


.1. Methodik der Validierung 
. Validierung am Miniatur-Modell 
. Validierung am Demonstrator 
. Validierung am Fallbeispiel aus der Industrie 


6. Schlussbetrachtung 


6.1. Zusammenfassung 
6.2. Diskussion 
6.3. Ausblick 


Abbildung 1.5: Aufbau der Arbeit 


14 


2 Grundlagen und 
Begriffsdefinitionen 


„Industrie 4.0“ steht als Begriff nicht nur für ein interdisziplinäres weites Feld 
an Methoden und Anwendungen, sondern stellt auch eine umfassende Initia- 
tive zur Modernisierung der industriellen Produktion dar. Entscheidendes 
Merkmal dieser Entwicklung ist die Vernetzung aller relevanten Elemente 
und damit die Kommunikationstechnologie, die es modernen Anlagen wie 
cyber-physischen Systemen erlaubt, „smart? zu agieren. Ziele sind neben 
ökonomischen Verbesserungen auch die Individualisierung der Produkte und 
engere Einbindung der Produktion in komplexe Lieferketten, um nur einige 
zu nennen. Mit dem menschlichen Werker kollaborierende Roboter können 
dazu einen Beitrag leisten, auch wenn mit der Gewährleistung der Arbeitssi- 
cherheit eine große Herausforderung vor die Anwendung gestellt ist. Etablier- 
te Standards stellen die Basis für die Kommunikation aller Komponenten 
dar: mit AutomationML steht eine XML-basierte Beschreibungssprache zur 
Verfügung, in der auch komplexe Anlagen abgebildet werden können. Ein 
weiteres mächtiges und im Kontext der vorliegenden Arbeit relevantes Werk- 
zeug ist OPC Unified Architecture (OPC UA), das nicht nur ein Datenmodell, 
sondern auch Protokolle und Lösungen für Sicherheitsfragen und weitere 
Module bereithält. Eine Einordnung der vorliegenden Arbeit in das Referenz- 
architekturmodell Industrie 4.0 (RAMI 4.0), das den theoretischen Rahmen 
bildet, rundet dieses Kapitel ab. 


2 Grundlagen und Begriffsdefinitionen 


2.1 Definitionen und Umfeld 


2.1.1 Industrie 4.0 und Industrial Internet of Things (lot) 


Nach der ersten (eigentlichen) industriellen Revolution gab es je nach zu 
Grunde gelegten Kriterien bis zu drei weitere, die sich jeweils durch ei- 
nen fundamentalen Wandel der zur industriellen Produktion zur Verfügung 
stehenden Mittel unterscheiden. Mit jeder weiteren Stufe stieg auch die Kom- 
plexität, was neben den damit verbundenen Chancen und Möglichkeiten auch 
den Bedarf an Methoden und Werkzeugen verstärkte, um diese zu handhaben. 
International wird die in Deutschland als vierte Stufe gesehene Entwicklung 
häufig auch als konsequente Fortsetzung der Automatisierung der dritten 
Stufe betrachtet (siehe auch Abbildung 2.1). 


So weit gefächert wie das Themengebiet ist auch die Menge existierender 
Definitionen für den Begriff „Industrie 4.0“, nach einer Studie des Indus- 
trieverbands BITKOM (Bauer und Horväth 2015) gibt es mindestens 104 
verschiedene. Die in Deutschland bedeutsame Forschungsplattform Plattform 
Industrie 4.0 (2018) bietet die folgende Definition an: 


Industrie 4.0 bezeichnet die intelligente Vernetzung von Ma- 
schinen und Abläufen in der Industrie mit Hilfe von Informations- 


und Kommunikationstechnologie. 


Für produzierende Unternehmen können sich daraus zahlreiche Vorteile erge- 
ben, zum Beispiel eine flexiblere digital gesteuerte Produktion mit besserer 
Auslastung der Maschinen, Erhöhung der Produktivität durch wandelbare 
Produktionsstraßen, individuellere Produkte nach Wunsch des Kunden, opti- 
mierte Logistik und eine ressourcenschonendere Kreislaufwirtschaft, um nur 


einige zu nennen. (Plattform Industrie 4.0 2018) 


2.1 Definitionen und Umfeld 


Cyber-physische 
Systeme 


SPS / Roboter 


Fließband 


Webmaschine 


Komplexität 


Spätes Frühes Frühe Heute 
18. Jh. 20. Jh. 1970er 


Abbildung 2.1: Vier industrielle Revolutionen und ihre wesentlichen Merkmale. Abbildung in 
Anlehnung an Thoben, Wiesner und Wuest (2017, S. 5). 


Aufgrund der Bedeutung der Industrie und insbesondere des Maschinen- und 
Anlagenbaus für die deutsche Wirtschaft wurde ein umfassendes Forschungs- 
programm, das ebenfalls den Titel „Industrie 4.0“, von der Bundesregierung 


ins Leben gerufen und mit entsprechenden Mitteln ausgestattet. 


Es basiert auf der Annahme, dass die „industrielle Produktion in näherer 
Zukunft charakterisiert sein wird durch eine starke Individualisierung der 
Produkte bei sehr flexibler Herstellung, intensive Integration der Kunden und 
Geschäftspartner in Geschäftsprozesse und die Verbindung der Produktion 
mit hochwertigen Serviceleistungen, die zu sogenannten hybriden Produkten 
führt.“ (Schütte 2012 cit. in Thoben, Wiesner und Wuest 2017) Industrie 4.0 
steht dabei auch für einen Paradigmenwechsel von der Automatisierung hin 
zu einem intelligenten Produktionskonzept. Die Grundlage dafür schaffen 
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Maschinen mit vernetzten Sensoren und Aktoren und Konzepte wie das 


„Internet der Dinge“. 


Das Internet der Dinge (,,Internet of Things“) ist ein Informationsnetzwerk 
bestehend aus physischen Objekten wie Sensoren, Maschinen, Fahrzeugen, 
Gebäuden und anderen Gegenständen, das es diesen Objekten erlaubt zu 
interagieren und zu kooperieren, um gemeinsame Ziele zu erreichen (Atzori, 
Iera und Morabito 2010). Die Anwendungsbereiche sind unterschiedlich und 
umfassen unter anderem den Verkehr, die Gebäudetechnik (Smart Home“), 
das Gesundheitswesen und die industrielle Produktion. Daher spricht man 
in letzterem Fall auch von dem „Industrial Internet of Things“ (IoT), das in 
Deutschland auch häufig mit dem Begriff „Industrie 4.0“ gleichgesetzt wird. 
Während der Begriff „Industrial Internet of Things“ eher die technische Seite 
umschreibt, ist mit „Industrie 4.0“ eher die ökonomische Seite gemeint. Das 
„Industrial Internet of Things“ führt also in gewissem Sinne zu „Industrie 
4.0“ (Jeschke u.a. 2017). 


2.1.2 Smart Manufacturing 


Ansätze wie Computer-Integrated Manufacturing (CIM), Product Data Man- 
agement (PDM) und auch Product Lifecycle Management (PLM) waren in 
den vergangenen rund 30 Jahren wichtige Meilensteine hin zu einer Digitali- 
sierung der industriellen Produktion und dennoch blieb diese auf Teilbereiche 
begrenzt. Das Ziel der digitalen Fabrik, wie sie aktuell angestrebt wird, ist 
die Integration aller Daten, Modelle, Prozesse und Software-Werkzeuge, 
so dass ein vollständiges digitales Modell der realen Fabrik entsteht, das 
für Kommunikation, Simulation und Optimierung über den gesamten Le- 
benszyklus genutzt werden kann (Jeschke u.a. 2017). Dabei wird sowohl 
die Anlage zur Produktion als auch das Produkt selbst digital abgebildet 


(„Digitaler Zwilling“). Es entsteht ein Netzwerk aus Informationsflüssen, in 


2.1 Definitionen und Umfeld 


dem reale und digitale Elemente sich wechselseitig beeinflussen (siehe auch 
Abbildung 2.2) 


Industrial Internet 
of Things (IloT) 


Internet of Industrie 4.0 


Things (loT) 


* Technische Integration von 
Cyber-Physischen Systemen in 
Produktion und Logistik 


* Nutzung des Internet of Things 
für industrielle Prozesse 


+ Wertschöpfung, 
Geschäftsmodelle, Dienste und 
Arbeitsorganisation 


Gesamtnetz 
Globale Informations- 
infrastruktur 


Cyberization 
Smarte Geräte und 
Menschen, Echtzeit- 
Verbindungen 


Abbildung 2.2: Industrial Internet of Things (IoT) als Schnittmenge des Internets der Dinge 
und der Cyber-Systeme in der Industrie in Anlehnung an Ovtcharova (2019). 


Neben technischen Aspekten, die die oben beschriebenen Ansätze teilweise 
gemeinsam haben und die auch nicht immer scharf gegeneinander abgrenzbar 
sind, wird beim Smart Manufacturing der Rolle des Menschen mit seinem 
Einfallsreichtum und Erfindergeist eine besondere Aufmerksamkeit zuteil. 
Die Möglichkeiten der menschlichen Arbeitskraft sollen nicht durch künst- 
liche Intelligenz und weitere Automatisierung ersetzt, sondern durch neue 
Werkzeuge erweitert werden. Dabei kommt den Produkt- und Prozessdaten 


eine besondere Bedeutung zu. (Thoben, Wiesner und Wuest 2017) 


2.1.3 Cyber-Physische Systeme 


Die NASA (2012) definiert Cyber-Physical System (CPS) wie folgt: 


Der Begriff „Cyber-physische Systeme“ beschreibt eine auf- 
kommende Klasse von physischen Systemen, die aufgrund sehr 


leistungsfähiger eingebetteter Softwarekomponenten komplexe 
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Verhaltensmuster beherrschen. Sie werden auch als hybride Sys- 
teme (Hardware und Software) oder als mechatronische Systeme 
(mechanisch und elektronisch) bezeichnet. Dies umfasst auch 
Komponenten mit Informationen und Wissen, das ihnen beispiel- 
lose Fähigkeiten in Bezug auf Interoperabilität und Interaktion, 
Belastbarkeit, Anpassungsfähigkeit und emergentes Verhalten 


verleiht. 


Andere Definitionen legen den Schwerpunkt entweder mehr auf den physi- 
schen oder den Software-Bereich, betonen weitere Komponenten wie Kom- 
munikation oder Kontrolle oder benennen einzelne Anwendungsgebiete. 
Kommen CPS in der Industrie zur Produktion zum Einsatz, werden sie als 
Cyber-Physical Production System (CPPS) bezeichnet. 


Unter dem Aspekt des Informationsmanagements führt die zunehmende 
Verbreitung cyber-physischer Systeme zu einer schrittweisen Ersetzung der 
etablierten hierarchischen Strukturen der Automatisierungspyramide durch 
vernetzte, dezentral organisierte und (teilweise) automatisierte Dienste, die 
auch cloud-basiert sein können. Dies wiederum erfordert neue Modellierungs- 
und Designtechniken zur Steuerung und Überwachung der Produktionspro- 
zesse. Dabei treten auch neue Herausforderungen bezüglich der Transparenz, 
Echtzeitfähigkeit, Robustheit und anderer Qualitätsmerkmale der Kommu- 
nikation auf. Eine weitere Anforderung entsteht durch die großen Mengen 
erhobener Daten auf der einen und der Notwendigkeit einer reduzierten An- 
zeige für den menschlichen Bediener solcher Systeme auf der anderen Seite. 
(Jeschke u.a. 2017, S. 9f) 


2.2 Mensch-Roboter-Interaktion 


Hinter Gitterzäunen und in Käfigen agierende Roboter sind ein in der In- 


dustrie seit Jahrzehnten vertrautes Bild. Die Arbeitsbereiche von Mensch 
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und Roboter sind aus Sicherheitsgründen über Jahrzehnte streng getrennt 
gewesen und daher fand die Montage eines Produkts oder eines Produktteils 
entweder rein manuell oder voll automatisiert statt. Lediglich eine nachein- 
ander automatisierte und manuelle Ausführung einzelner mehr oder weniger 


großer Montageschritte war in dieser Situation möglich. 


Die Kombination der besonderen Fähigkeiten von Mensch und Roboter, 
in Tabelle 2.1 überblicksartig dargestellt, entfaltet ein höheres technisches 
und ökonomisches Potenzial und entlastet den Werker von gefährlichen und 
belastenden Aufgaben. Eine umfassendere Zusammenstellung dazu geben 
Bauer, Bender u.a. (2016, S. 24). 


Ein zentraler Aspekt der vorliegenden Arbeit ist die gemeinsame Montage 
eines Produkts durch Mensch und Roboter, die also zur Erreichung dieses 
Ziels in irgendeiner Form in Interaktion treten müssen. Dies betrifft einerseits 
die mechanisch-physische Interaktion, die teilweise auch unerwünscht sein 
kann (siehe Abschnitt 2.2.2), andererseits aber auch die informationelle 
Schnittstelle zwischen Mensch und Roboter (siehe Abschnitt 2.2.3). Die Art 
der Interaktion bei der Montage kann dabei, wie in Abschnitt 2.2.1 dargestellt, 


ganz unterschiedlich sein. 


Tabelle 2.1: Unterschiedliche Stärken von Mensch und Roboter 


Mensch Roboter 

Flexibilität Präzision 

Hohe Lernfahigkeit | Kraft 

Erfahrung Exakte Wiederholbarkeit 
Improvisation Schnelligkeit 
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2.2.1 Formen der Zusammenarbeit 


Das Kunstwort „Cobot“, zusammengesetzt aus „Collaborative“ und „Robot“, 
findet seine erste Erwähnung bei Colgate, Wannasuphoprasit und Peshkin 
(1996) und wird dort wie folgt definiert: 


„Ein ’Cobot’ ist ein Roboter, der gemeinsam mit einem mensch- 


lichen Bediener Objekte manipuliert.“ 


Eine spätere Definition der selben Autoren betont zusätzlich den gemeinsa- 
men Arbeitsraum, in dem Roboter und Mensch sich bewegen und arbeiten. 
Das Vorhandensein dieses gemeinsamen Arbeitsraums, seine Beschaffenheit 
und der zeitliche Ablauf der darin stattfindenden Prozesse ziehen Bauer, 
Bender u.a. (2016) als grundlegendes Kriterium zur Unterscheidung ver- 
schiedener Stufen der Interaktion zwischen Mensch und Roboter heran (siehe 
Abbildung 2.3), um die teilweise synomym oder zumindest uneindeutig ver- 
wendeten Begriffe „Koexistenz“, „Kooperation“, „Kollaboration“, etc. präzise 


unterscheiden zu können. 


Als Cobots kommen meistens Leichtbauroboter zum Einsatz, die nicht nur 
leicht transportierbar und aufzustellen sind, sondern auch oft intuitiv bedien- 
bare Programmierschnittstellen haben und über Sicherheitsvorrichtungen wie 


beispielsweise eine Sensorik zur Kollisionskontrolle verfügen. 


Nach Bauer, Bender u.a. (2016) werden basierend auf der Existenz und 
Nutzung des gemeinsamen Arbeitsraums von Mensch und Roboter die in 
Tabelle 2.2 erläuterten Formen der Interaktion unterschieden (siehe auch 
Abbildung 2.4). 


Der Fall der echten Kollaboration ist (noch) in der Industrie selten zu finden, 
die Koexistenz und die Kooperation stellen aktuell noch den Großteil aller in 


der Praxis angewandten Interaktionsformen dar. 
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Gemeinsamer 
Arbeitsraum 


Arbeitsraum Werker 


Abbildung 2.3: Arbeitsräume von Mensch und Roboter als Grundlage der Klassifikation des 
Grades der Zusammenarbeit nach Bauer, Bender u. a. (2016) (verändert). Die 
Überlappung der beiden Arbeitsräume bildet den gemeinsamen Arbeitsraum. 


Im Folgenden wird in einem übergreifenderen Sinne der Begriff „Kollabo- 
ration“ bzw. „kollaborativ“ verwendet, da die übrigen Interaktionsformen 
Spezialfälle der Kollaboration und die dabei zu erwartenden Ereignisse und 
Problemstellungen jeweils echte Teilmenge der bei der kollaborativen Mon- 


tage auftretenden Fragestellungen sind. 


2.2.2 Sicherheit der Interaktion 


Absolute Voraussetzung für den Verzicht auf trennende physische Sicher- 
heitskomponenten wie Schutzzäune und die Errichtung eines gemeinsamen 
Arbeitsraums für Mensch und Roboter ist die Herstellung der Sicherheit vor 
Verletzungen des Werkers auf anderem Wege. Dazu kommen verschiedene 
Ansätze in Betracht, die im Folgenden näher erläutert werden. 


Grundsätzlich ist in einem gemeinsamen Arbeitsraum von Mensch und Ro- 


boter eine gegenseitige Berührung nicht vollständig auszuschließen. Die 
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Tabelle 2.2: Formen der Interaktion zwischen Mensch und Roboter in Anlehnung an Bauer, 
Bender u.a. (2016). 


Zelle 


Koexistenz 


Synchronisiert 


Kooperation 


Kollaboration 


technische Spezifikation DIN ISO/TS 15066, die die Sicherheit kollaborati- 
ver Roboter zum Gegenstand hat, basiert auf der Prämisse, dass eine solche 
Berührung nicht zu Schmerzen oder einer Verletzung führen darf. Dies kann 
häufig durch eine Begrenzung der Robotergeschwindigkeit erreicht werden, 
die jedoch wiederum einen negativen Einfluss auf die Effizienz hat. Aber 
auch das Design des Roboters und seiner Werkzeuge kann einen Beitrag zur 


Sicherheit liefern, zum Beispiel durch sensitive Oberflächen oder Greifer, die 


Es gibt keine echte Interaktion, da kein gemeinsamer Ar- 
beitsraum existiert, sondern Mensch und Roboter durch ei- 
nen Schutzzaun physisch voneinander getrennt sind. 


Mensch und Roboter arbeiten nebeneinander, nicht physisch 
voneinander getrennt durch einen Zaun, aber es existiert kein 
gemeinsamer Arbeitsraum. 


Mensch und Roboter haben zwar einen gemeinsamen Ar- 
beitsraum, in dem sich aber immer nur einer von beiden 
bewegt, so dass die Trennung nicht räumlich, sondern zeit- 
lich erfolgt. 


Im gemeinsamen Arbeitsraum von Mensch und Roboter 
können beide gleichzeitig agieren, arbeiten aber nie am sel- 
ben Gegenstand, sondern bearbeiten verschiedene Objekte 
zur selben Zeit. 


Mensch und Roboter arbeiten gleichzeitig und zusammen 
im gemeinsamen Arbeitsraum am selben Objekt. 


konstruktionsbedingt nicht zu Verletzungen führen können. 


Die Spezifikation DIN ISO/TS 15066 beschreibt vier Betriebsarten kollabo- 


rativer Robotik: 
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Zelle Koexistenz Synchronisiert Kooperation Kollaboration 


Ed 


Abbildung 2.4: Verschiedene Formen der Zusammenarbeit zwischen Mensch und Roboter unter 
den Aspekten gemeinsamer Arbeitsräume und Synchronität der Bearbeitung 
nach Bauer, Bender u.a. (2016). 


Sicherheitsbewerteter überwachter Halt 

Der Roboter wird vor der Interaktion mit dem Menschen gestoppt. Derartige 
Anwendungen sind von jedem Industrieroboter ausführbar, auch von solchen, 
die nicht für Kollaboration vorgesehen sind. Dieser Modus kommt in Frage, 
wenn der Roboter einen Großteil der Arbeit alleine erledigen kann und der 


Mensch nur selten eingreift, zum Beispiel um ein Werkzeug zu justieren. 


Handführung 

Der Roboter wird von Hand geführt und bewegt sich nur mit geringer Ge- 
schwindigkeit. Dies dient im Allgemeinen zur Programmierung des Roboters 
(„Teaching“). 


Leistungs- und Kraftbegrenzung 

Die von dem Roboter maximal ausgehenden Kräfte werden, zusammen 
mit Leistung und Geschwindigkeit, auf einen Wert reduziert, der nicht zu 
Verletzungen führen kann. Dabei ist es unerheblich, ob der physische Kontakt 


zwischen Mensch und Roboter beabsichtigt oder unbeabsichtigt stattfindet. 
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Dazu gehört auch die Gestaltung des Roboters ohne scharfe Kanten, mit 
weichen Oberflächen und mit Sensoren, die eine Reaktion auf zu hohe Kräfte 


ermöglichen. 


Geschwindigkeits- und Abstandsüberwachung 

Durch Sensoren wie Laserschranken oder Kameras wird der gemeinsame 
Arbeitsraum und die Bewegung des Menschen darin permanent überwacht 
und die Bewegung des Roboters in Abhängigkeit von dem aktuellen Abstand 
zum Mensch verlangsamt oder sogar vollständig gestoppt. Mit wieder zu- 
nehmendem Abstand des Menschen kann der Roboter dann wieder zu einer 


schnelleren Bewegung zurückkehren. 


2.2.3 Die Schnittstelle Mensch-Maschine 


Eine zweckdienliche Kommunikation zwischen Roboter und Mensch ist die 
Grundlage der Kollaboration und gleichzeitig auch der Sicherheit. Es gibt 


dabei mehrere Kommunikationsziele, zum Beispiel: 


e Programmierung des Roboters 
e Synchronisation der Aktionen 


e Handlungsanweisungen Mensch <> Roboter 


Neben einfachen Schaltern, zum Beispiel zur Bestätigung einer Aktion, oder 
Bildschirmen zur Anzeige von Informationen für den Menschen, können 
dabei je nach Anwendungsfall auch eine Vielzahl weiterer Möglichkeiten in 
Betracht kommen. Dabei ist insbesondere die Qualifikation des Menschen, 
aber auch der Grad der intuitiven Nutzbarkeit durch den Menschen zu be- 
rücksichtigen. Bei der Programmierung des Roboters ist das Lernen durch 
Führen des Roboters oder Beobachten einer vom Menschen ausgeführten 


Aktion ein gängiger Ansatz (Papadopoulos u.a. 2017). 
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Zur Synchronisation der Kollaboration oder Austausch von Anweisungen 
kommt auch die Steuerung durch natürliche Sprache in Betracht, die einer- 
seits ein großes Potenzial bietet, da sie die für den Menschen natürlichste und 
schnellste Form der Kommunikation ist. Andererseits ist erkennbar gewor- 
den, dass die hohen Erwartungen nicht restlos erfüllt werden können und die 
Anwendbarkeit der Sprachsteuerung an enge Grenzen gebunden ist (Moore 
2017). Insbesondere kann dieser Ansatz auch einer Internationalisierung im 
Wege stehen. In lauten Arbeitsumgebungen mit vielen Störgeräuschen kann 
es zu Problemen mit der Sprachsteuerung kommen. In diesem Fall können 
verschiedene Aktionen des Menschen wie Handgesten oder andere Bewe- 
gungen ebenfalls zur Kommunikation verwendet werden, indem sie durch 
Videokameras erfasst und entsprechend ausgewertet werden. Umgekehrt ist 
es auch möglich den Roboter bestimmte Gesten (Bewegungsmuster) ausfüh- 
ren zu lassen, deren Bedeutung dem Menschen durch Training oder Intuition 
bekannt sind (Sheikholeslami, Moon und Croft 2017). 


Mit Virtual Reality (VR) und Augmented Reality (AR) stehen weitere Kom- 
munikationswege zur Verfügung, deren Potenzial bei der Anwendung mit 
kollaborativen Robotern noch Gegenstand der aktuellen Forschung ist. Nicht 
nur die Programmierung von Roboterbewegungen, sondern auch die Rück- 
meldung über visuelle, akustische oder haptische Reize kann Gegenstand 
der VR/AR-Anwendung sein. Unabhängig von der konkreten technischen 
Realisierung muss in jedem Fall das Hauptaugenmerk bei der Gestaltung der 
Mensch-Roboter-Interaktion, insbesondere für die kollaborative Montage, 
auf der Vielfalt der menschlichen Individuen, deren Lernhintergründen und 
demographischen, ethischen, physischen und sozialen Eigenschaften liegen. 
(Jost u.a. 2016, S. 7f) 


Der Mensch als die mit Abstand flexibelste „Komponente“ kann im Industrie- 
4.0-Umfeld verschiedenste Rollen einnehmen, wobei seine Hauptaufgabe die 
Spezifikation und Überwachung der Aufgaben der cyber-physischen Systeme 


sein wird. Zusätzlich übernimmt er alle erforderlichen manuellen Eingriffe, 
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die erforderlich sind, unterstützt von mobilen kontextsensitiven Schnittstellen 
und Assistenzsystemen. Damit nimmt er die Rollen eines strategischen Ent- 
scheidungsträgers und flexiblen Problemlösers im Gesamtsystem ein. Daraus 
ergibt sich auch der Bedarf für neue Qualifikationswege, um das erforderli- 
che interdisziplinäre Verständnis für Industrie 4.0 zu schaffen. (Gorecky u.a. 
2014) 


2.3 Montage variantenreicher Produkte 


„Gegenstände ähnlicher Form und/oder Funktion mit in der Regel hohem 
Anteil identischer Gruppen oder Teile“, so werden in der DIN 199 Varianten 
definiert. Bei vielen Produkten gibt es die Nachfrage nach verschiedenen 
Varianten, die zahlreiche Ursachen haben kann, seien es gesetzliche Anfor- 
derungen in verschiedenen Ländern oder Absatzmärkten, unterschiedliche 
Anwendungen oder auch technische Weiterentwicklungen (siehe auch Ab- 
bildung 2.5). Die individuellen Kundenwünsche ökonomisch sinnvoll zu 
erfüllen verlangt von den herstellenden Unternehmen eine effiziente Produk- 
tion und ein entsprechendes Varianten- und Komplexitätsmanagement. Dabei 
wird die Varianz häufig in der Montage durch Modularisierung abgebildet, in- 
dem aus einzelnen Teilen oder Baugruppen durch Kombination verschiedene 


Produkte hergestellt werden. 


2.3.1 „Mass Customization“ 


Das Oxymoron „Mass Customization“, zusammengesetzt aus den beiden 


Begriffen „Mass Production“ und „Customization“, die sich zu widerspre- 


28 


2.3 Montage variantenreicher Produkte 


Globalisierung 


Verkürzung des Intensiver 


Produktlebenszyklus Markte Wettbewerb 


Differenzierung 


International der Zulieferer 
verteilte > 
Fertigungsstätten Sättigung der 
Absatzmärkte 
Beschleunigung des i 
Innovationsrhythmus Zyklische 
Systeme Strategien Schwankungen 
der Nachfrage 
Unternehmen 
Strukturen Prozesse 
Technologiewandel % W 
Technologie Gesellschaft 
SC Wertewandel 
Flexibilisierung 
der 
Produktions- 


Individualisierung 
einrichtungen 


Vereinfachung, Beschleunigung 


und Kostenreduktion des Demographischer 
globalen Informations- und Wandel 
Warenaustausches 


Abbildung 2.5: Ursachen zunehmender Variantenvielfalt nach Grotkamp (2010), zitiert in 
Thiebes und Plankert (2014, S. 187). 


chen scheinen, wurde erstmals von Davis (1987) wie folgt verwendet und 
definiert: 


„Mass Customization of markets means that the same large 
number of customers can be reached as in mass markets of 
the industrial economy, and simultaneously they can be trea- 


ted individually as in the customized markets of pre-industrial 
economies.“ 


Piller (2006, S. 358), der die deutsche Ubersetzung „Kundenindividuelle Mas- 
senproduktion“ vorschlägt, sieht in ihr eine ,,’informationsbasierte’ Produkti- 


on, in der der Handhabung und Verarbeitung von Information im Wertschöp- 
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fungsprozess die entscheidende Rolle zukommt.“ Diese Informationsflüsse 
stellt Abbildung 2.6 schematisch dar. 


Wünsche/Bedürfnisse des Kunden 


Erfahrungen während der 


2 Produktnutzung, Folgebedarfe 


Distribution und Wiederholungskauf Erstkauf 
Beziehungsmanagement Nutzung des Erhebung der Individualisierungsfunktion 
Individuelle Auslieferung, Kundenwissens (Einsatz von Produktkonfiguratoren) 


Aufbau einer Learning 
Relationship und Aggregation a J 


zu Kunden-Know-how 


Produktionsplanung 
A Variantenmanagement, Auftragsverwaltung, 
Ferti CAD, Bildung der Fertigungsauftrage, 
'gung í Reihenfolgenplanung und Freigabe 
Steuerung der flexiblen Fertigung 


(CNC-Maschinen) J 
Steuerung der auftragsneutralen Vorfertigung 


Kanban-Regelkreise 


Lieferanten 
Übermittlung der 
Individualisierungsinformation 


Abbildung 2.6: Der Informationskreis der Mass Customization in Anlehnung an Piller (2006, 
S. 359). 


Eine Schlüsselrolle beim Informationsmanagement zur kundenindividuel- 
len Massenproduktion kommt Produktkonfiguratoren (siehe auch Unterab- 
schnitt 2.3.2) zu, mit deren Hilfe der Kunde (oder auch der Vertrieb) selbstän- 
dig regelbasiert seine individuelle Produktvariante zusammenstellen kann. 
Die kundenindividuelle Massenproduktion wird ökonomisch jedoch erst 
durch den Einsatz wandlungsfähiger Maschinen und Roboter ermöglicht 
(Piller 2010). 


Während die „Mass Customization“ also die Variantenvielfalt mit den Vortei- 
len der Massenproduktion zu vereinbaren versucht, geht der bei Y. Wang u.a. 
(2017) beschriebene Ansatz der „mass personalization“ darüber hinaus und 
nutzt die Konzepte der Industrie 4.0 zur Herstellung persönlicher Produkte, 


deren Produktion dennoch kosteneffizient ist. 
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2.3.2 Produktkonfiguration 


Die durch Variation und Auswahl einzelner Komponenten theoretisch herstell- 
baren Varianten eines Produkts sind bei vielen Produkten äußerst zahlreich. 
Die maximale Anzahl möglicher Varianten wird im Allgemeinen in der Praxis 
eingeschränkt durch Regeln ("Constraints"), die bestimmte Kombinationen 
nicht zulassen, weil sie kein sinnvolles Produkt ergeben. Ein in dieser Ar- 
beit noch mehrfach exemplarisch angeführtes Produkt zur Steuerung von 
Türzuhaltungen kann einen Not-Stopp-Schalter und andere Bedienelemente 
beinhalten, die frei wählbar sind. Zwei oder mehrere Not-Stopp-Schalter 
im selben Produkt miteinander zu kombinieren wäre jedoch nicht sinnvoll, 
so dass dies durch eine Regel ausgeschlossen wird. Zur Unterstützung des 
Vorgangs der Konfiguration kommen Produktkonfiguratoren zum Einsatz, die 
dem jeweiligen Benutzer zulässige Varianten anzeigen und nach abgeschlos- 
sener Auswahl eine Beschreibung der Produktvariante generieren. Auf dieser 
Basis können in nachgelagerten Prozessen weitere Informationen abgeleitet 


werden, zum Beispiel zur Steuerung der Montage. 


2.4 Grundlegende Standards 


Die vorliegende Arbeit baut auf mehreren aktuellen Industriestandards auf, 
die in den letzten Jahren Gegenstand intensiver Forschung waren und die sich 
bereits auch in der Praxis etabliert haben oder gerade im Begriff sind, sich zu 
etablieren. Trotz ihrer relativen Aktualität und weiterhin hohen Bedeutung 
für die laufende Forschung werden sie in den folgenden Unterabschnitten als 


Grundlagen vorgestellt. 
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2.4.1 AutomationML 


Bei AutomationML! handelt es sich um ein offenes XML-basiertes Da- 
tenaustauschformat zum Austausch von Engineering-Daten, das in IEC 
62714 standardisiert ist. Es dient zur Integration verschiedener Engineering- 
Werkzeuge über die Disziplinen Mechanisches Design, Elektrisches Design, 
HMI-Entwicklung oder SPS-Programmierung hinweg bis zur Ansteuerung 
von Robotern. Dabei ist AutomationML objektorientiert und beschreibt daher 
Anlagen als hierarchische Objektstruktur auf allen verfügbaren Detaillie- 
rungsstufen. Dabei verwendet AutomationML weitere selbständige Formate 
wie Computer Aided Engineering Exchange (CAEX) oder COLLAborative 
Design Activity (COLLADA), die in den einzelnen Domänen etabliert sind. 
Darüber hinaus können zusätzliche XML Formate eingebettet werden, um 
spezielle weitere Anforderungen zu erfüllen. Auf diese Weise ist der Standard 


auch offen für zukünftige Entwicklungen und Erweiterungen. 


Abbildung 2.7: Schematischer Aufbau von AutomationML in Anlehnung an Lüder und 
Schmidt (2016, S. 14). 


l nttps://www.automationml.org 
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Einzelne Bestandteile des zusammengesetzten AutomationML-Formats und 


die zugehörigen integrierten Standards sind: 
e Topologie: CAEX (IEC 62424) 
e Geometrie: COLLADA 
e Kinematik: COLLADA 
e Logik: PLCopen XML 


Die Integration der einzelnen Formate illustriert Abbildung 2.7 auf der vor- 


herigen Seite. 


2.4.2 OPC UA 


OPC UA ist ein hersteller- und plattformunabhängiges Paket von Standards 
für den M2M-Datenaustausch im Umfeld der industriellen Automation und 
wird von der OPC Foundation? gepflegt und weiterentwickelt. Basierend auf 
früheren Versionen (wie OPC Classic) bietet die OPC Unified Architecture 
jedoch weit mehr als nur den Zugriff auf aktuelle Daten, sondern umfasst auch 
deren semantische Beschreibung, die Lösung zahlreicher Sicherheitsaspekte, 
ein umfassendes und erweiterbares Datenmodell oder auch den Zugriff auf 
historische Daten. Mit OPC UA wird also nicht nur der Transport im Sinne 
eines Protokolls beschrieben, sondern auch die Definition von Schnittstellen. 
Zudem wird die semantische Beschreibung aller Assets erleichtert und der 


Transport der Daten definiert. 


Wesentlicher Teil der serviceorientierten Architektur (SOA) ist auch ein gan- 
zer Stack von Kommunikationsschichten auf Basis des Internetprotokolls 


(IP). Zur Verfügung stehen zwei verschiedene Übertragungsprotokolle: ein 


? https://opcfoundation. org 
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IEC, EDDL, FDT, PLCopen, ... 


D D Ei OPC UA Informationsmodell 


Basis 


Abbildung 2.8: Architektur von OPC UA in Anlehnung an Mahnke, Leitner und Damm (2009). 
DA: Data Access, AC: Alarms & Conditions, HA: Historical Access, Prog: 
Programs. 


binäres mit optimierter Performance und Interoperabilität und ein SOAP- 
basierter Webservice. Auf dieser Basis stellt OPC UA verschiedene Dienste 
zur Verfügung für den Datenzugriff oder auch die Ausführung von Program- 
men und deren Monitoring. Weiterhin sieht die Architektur die Erweiterung 
des Basisdatenmodells durch domänenspezifische weitere Modelle vor, die 
in den sog. „Companion Specifications“ beschrieben und typischerweise von 
anderen Organisationen entwickelt werden (siehe auch Abbildung 2.8). Ihr 
Gültigkeitsbereich ist ebenfalls herstellerübergreifend, aber zusätzlich lässt 
OPC UA auch herstellerspezifische Erweiterungen zu (s. a. Pauker, Frühwirth 
u.a. 2016). 


Das Informationsmodell ist kein hierarchisches, sondern ähnelt Datenmo- 
dellen aus der objektorientierten Programmierung. Es besteht aus Knoten 
(,,Nodes“, vergleichbar den Objekten), die Attribute haben und aufrufbare 
Methoden mit Rückgabewerten definieren können. Untereinander können die 
Knoten in unterschiedlicher Weise miteinander verbunden sein und ein Netz 
bilden. Insbesondere die Möglichkeit, auch Metadaten und Diagnosedaten 
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über die Knoten zur Verfügung zu stellen, zeichnet OPC UA aus. (Mahnke, 
Leitner und Damm 2009) 


Die meisten OPC UA Anwendungen basieren auf dem Client-Server-Modell. 
Eine Anwendung, die Informationen für andere Systeme zur Verfügung 
stellt, ist ein UA Server, eine Anwendung, die diese abrufen ("konsumie- 
ren") kann, ist ein UA Client. In vielen Fällen stellt eine Anwendung beide 
Rollen zur Verfügung, ist also gleichzeitig ein UA Server und ein UA Cli- 
ent (Mahnke, Leitner und Damm 2009). Dies könnte beispielsweise ein 
Roboter sein, der einerseits Statusinformationen und Messwerte zur Verfü- 
gung stellt (als UA Server), und andererseits als UA Client Steuerparameter 
bei einem anderen UA Server abruft. Alternativ stellt OPC UA auch einen 
Publish-Subscribe-Ansatz zur Verfügung, der besonders für Embedded Sys- 
tems und Cloud-basierte Lösungen in Frage kommt. Dabei besteht zwischen 
den kommunizierenden Systemen keine dauerhafte Verbindung, sondern der 
Publisher kann verbindungslos senden, Subscriber diese Daten empfangen 


und weiterverarbeiten. 


Die in diesem Unterabschnitt vorgestellte Architektur (OPC UA) und die in 
Unterabschnitt 2.4.1 beschriebene AutomationML stehen aber keineswegs 
ohne Berührungspunkte nebeneinander, sondern lassen sich auch erfolgreich 
gemeinsam nutzen. Ziel dieser Kombination kann eine Verringerung des 


Aufwands zur Inbetriebnahme im Sinne von „Plug and work“ sein. 


„Plug and work“ ist die Forderung, die Interoperation zwischen 
zwei oder mehr Beteiligten mit minimalem Arbeitsaufwand her- 
zustellen, zu ändern oder aufzulösen. 

(Schleipen 2018, S. 159ff) 


Dabei dient AutomationML der Beschreibung der Anlagen, OPC UA der 
Kommunikation. Schleipen (2018) beschreibt bildlich: ,,AutomationML ist 
das Werkzeug, das vom Handwerker OPC UA eingesetzt wird, um etwas 
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zu erreichen.“ Auch existiert schon eine spezielle OPC UA Companion 


Specification zur Integration von AutomationML. 


2.4.3 Referenzarchitekturmodell Industrie 4.0 


Das RAMI 4.0 ist ein gemeinsam von mehreren Industrieverbänden entwi- 
ckeltes dreidimensionales Modell zur Erfassung eines Produkts über den 
gesamten Lebenszyklus mit dem Ziel einer durchgängigen Erfassung und 
Abbildung auf IT-Ebene. Auf Basis einer serviceorientierten Architektur 
bietet es einen Orientierungsrahmen, in dem komplexe Prozesse eindeutig 
eingeordnet und auch in überschaubarere Pakete unterteilt werden können. 
Ein weiteres Ziel des RAMI 4.0 ist die Herstellung einer einheitlichen Be- 
grifflichkeit für die interdisziplinäre Zusammenarbeit an Themen im Industrie 
4.0 Umfeld. 


Abbildung 2.9: Referenzarchitekturmodell Industrie 4.0. Quelle: Plattform Industrie 4.0° 


’https://www.plattform-i40.de 
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Die erste seiner drei Achsen (,,Hierarchy Levels“, in Abbildung 2.9 von der 
Mitte nach rechts weisend) ersetzt in gewissem Sinne die überwiegend durch 
die Hardware vorgegebenen hierarchischen Strukturen der klassischen Auto- 
matisierungspyramide, an deren Stelle eine Art Peer-to-Peer-Netzwerk tritt, 
innerhalb dessen ohne Hierarchie-Ebenen kommuniziert wird. Die zweite 
Achse (von unten nach oben) bildet die verschiedenen Schichten von der 
realen physischen Welt über die Integration in digitale Ökosysteme über 
verschiedene Kommunikationsschichten bis zur Geschäftsprozesslogik ab. 
Die dritte Achse (links) steht für den Produktlebenszyklus von der Entwick- 
lung bis zu Gebrauch und Wartung, wobei die erste Hälfte („Type“) sich auf 
die digitale Produktentstehung bezieht, die zweite Hälfte (‚‚Instance‘) die 
Produktion realer Instanzen dieses Typs beschreibt. (Heidel 2017) 


Ergänzt wird das RAMI 4.0 durch die Industrie-4.0-Komponente, einem 
Modell zur Kapselung von realen Objekten (,,Assets“) mit einer digitalen 
Zwischenschicht (,, Verwaltungsschale“) mit dem Ziel, diese Objekte in der 


digitalen Welt verfügbar zu machen. 


Die in der vorliegenden Arbeit untersuchten Gebiete sind innerhalb des 
RAMI 4.0 hauptsächlich auf den Ebenen Communication, Information und 
Functional zu finden, beziehen sich unter dem Aspekt des Produktlebens- 
zyklus’ vorwiegend auf die Bereiche Development und Production und im 


Sinne der Hierarchie auf die Ebenen Control Device und Station. 


2.5 Zusammenfassung 


Die Chancen der unter dem Begriff „Industrie 4.0“ zusammengefassten Akti- 
vitäten und Entwicklungen basieren auf der Möglichkeit der informationellen 
Vernetzung aller beteiligten Objekte, dem Industrial Internet of Things. Diese 
Chancen zu nutzen setzt ein neues Informationsmanagement voraus, in dem 


bisherige Paradigmen keine oder nur noch begrenzte Gültigkeit haben. An 
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die Stelle der Automatisierungspyramide treten neue Strukturen, die Grenze 
zwischen Business IT und Production IT verschwimmt. Cyber-physische 
Systeme bilden die Verbindung zwischen der virtuellen und der realen Welt, 
sie setzen die Idee in ein materielles Produkt um und liefern ihrerseits wie- 
der zahlreiche Daten zurück, aus deren Analyse neue Schlussfolgerungen 
für die Produktion möglich werden. Dem Menschen kommt in dieser neu- 
en Form der industriellen Montage einerseits die Rolle des Planers und 
Problemlösers zu, andererseits kann er auch im Rahmen der kollaborativen 
Montage als Werker besondere menschliche Fähigkeiten mit denen von Ro- 
botern kombinieren. Je nach Art und Grad der Zusammenarbeit reicht das 
Spektrum der Kollaboration von Roboter und Mensch dabei von der seit 
langem angewandten Trennung durch Schutzeinrichtungen bis zur unmittel- 
baren gemeinsamen Aktion in einem ebenfalls gemeinsamen Arbeitsraum. 
Die entstehende Flexibilität der Montageeinheiten gibt Herstellern die Mög- 
lichkeit einer kundenindividuellen Produktion mit einer Kostenstruktur, die 
der Serienproduktion nahe kommt. Ermöglicht wird all dies erst durch die 
Etablierung umfangreicher Informationsflüsse im Engineering, in der An- 
lagensteuerung und zur Geschäftsebene hin. Mit AutomationML steht ein 
relativ neuer Standard zur flexiblen semantischen Beschreibung von Assets 
zur Verfügung, der in Kombination mit OPC UA als Architektur für die 
Kommunikation insbesondere aufgrund der Möglichkeiten zur semantischen 
Beschreibung ein hohes Potenzial entfaltet. Das RAMI 4.0 bietet die notwen- 
dige theoretische Orientierung zur Einordnung von Werkzeugen, Protokollen 


und Architekturen. 
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Die Anforderungen an ein kollaborationsgerechtes Wissens- und Prozess- 
management sind vielfältig und kommen aus mehreren thematischen Teil- 
bereichen. Neben den grundsätzlichen Eigenschaften der Anlage selbst und 
ihren Kommunikationsfähigkeiten spielen auch die optimale Ableitung von 
Arbeitsplänen, die Berücksichtigung mehrerer Standards, die virtuelle Absi- 
cherung und Simulation, aber auch die Persistierung und Analyse anfallender 
Daten eine Rolle. Den aktuellen Stand der Forschung auf diesen Gebieten 
fasst der folgende Abschnitt zusammen, den Stand der praktischen Anwen- 


dung in der Industrie der daran anschließende. 


3.1 Stand der Forschung 


Die Fortschritte in der Roboter-Technologie haben dazu geführt, dass trotz ho- 
her Sicherheitsanforderungen die Kollaboration und Kooperation von Werker 
und Roboter möglich geworden ist. Durch die Entwicklung von Leichtbauro- 
botern, die häufig als Cobots eingesetzt werden, ist die früher erforderliche 
räumliche Trennung zwischen Mensch und Roboter nicht mehr grundsätzlich 
erforderlich. Eine der zahlreichen Herausforderungen auf dem Gebiet der 
kollaborativen Montage ist die informationstechnische Abbildung der Pro- 
duktionsumgebung (Werker, Cobot, weitere Werkzeuge, etc.) zur Unterstüt- 


zung der Montage. Dabei müssen alle beteiligten Komponenten miteinander 
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kommunizieren können, so dass sowohl für den Roboter als auch für den 
Menschen verständliche Sprachkonzepte zur Verfügung stehen (Sadik und 
Urban 2017). 


Neben der Sicherheit des Werkers, der Erkennung seiner Aktivitäten und der 
Integration der Zelle in den Betrieb identifizieren Sadik und Urban (2017) 


insbesondere die folgenden Forschungsaufgaben und Herausforderungen: 


Kooperative Aufgabenplanung 

Welche Aufgabe übernimmt der Cobot, welche der Werker, welche wird 
gemeinsam (echt kollaborativ) erledigt? Ein gängiger Ansatz ist die statische 
Planung basierend auf den jeweiligen Kompetenzen und der zu erwarten- 
den Auslastung. Dazu werden die Fähigkeiten des Cobots und des Werkers 
systematisch beschrieben, ebenso auch die bei der Montage auszuführenden 
Aufgaben. Einen einfachen Ansatz des paarweisen Vergleichs für jede Auf- 
gabe beschreiben Müller, Vette und Mailahn (2016). Durch Beobachtung der 
Effizienz bei der Ausführung, insbesondere des Werkers, und Rückkopplung 
in die automatisierte Planung und die CAD-basierte Simulation des gemeinsa- 
men Arbeitsplans kann die Zusammenarbeit weiter optimiert werden (Sadik 
und Urban 2017). 


Darstellung fertigungsbezogener Informationen 
Die Gesamtheit der relevanten Objekte einschließlich des Werkers in einer 
kollaborativen Umgebung mit geeigneten Metadaten zu beschreiben sehen 
Sadik und Urban (2017) als notwendige Voraussetzung. Diese ist dann auch 
Grundlage der oben beschriebenen Aufgabenplanung. 


Zugang zu fertigungsbezogenen Informationen 


Eine weitere zentrale Frage ist diejenige nach dem geeigneten Kommuni- 
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kationsmittel, um alle relevanten Informationen (z. B. Arbeitsanweisungen) 


sowohl an den Roboter als auch den Werker übermitteln zu können. 


Logik zur Verarbeitung fertigungsbezogener Informationen 

Zur Verarbeitung der fertigungsbezogenen Daten bedarf es einer geeigneten 
Logik, mit deren Hilfe sich jede Komponente an neue veränderte Anforde- 
rungen in der Produktion anpassen kann. Dabei muss jeder Teil der Anlage 
in der Lage sein, die Anforderungen und den gesamten Status der Anlage 
zu erkennen und seine jeweilige Funktion zu erfüllen (Sadik und Urban 
2017). 


Thoben, Wiesner und Wuest (2017) leiten aus drei Anwendungsbeispielen 
für Industrie 4.0 Forschungsbedarf auf verschiedenen Gebieten, insbesonde- 
re unter technischen, methodischen und die Geschäftsmodelle betreffenden 
Aspekten ab. Globalisierte Lieferketten bestehen aus einer Vielzahl von 
Partnern mit heterogenen IT-Lösungen, deren für Industrie 4.0 erforderliche 
Interoperabilität eine der Kernfragen aktueller und zukünftiger Forschung 
ist. Die Integration aller beteiligten Objekte in das „Smart Manufacturing“ 
und die entsprechenden Netzwerke, Lieferketten und Produktionslinien kann 
nach Thoben, Wiesner und Wuest (2017) nur mit Hilfe allgemein akzeptierter 
Standards gelingen. Ein weiteres Forschungsgebiet bildet die Analyse der 
an zahlreichen Sensoren entstehenden großen Datenmengen (,,Big Data“), 
insbesondere die algorithmische und grafische Aufbereitung dieser Daten zur 
Unterstützung von Entscheidungen des Menschen. Ein Beispiel ist die zuver- 
lässige Bilderkennung im Umfeld von Cobots zur Erkennung und Vorhersage 
von Bewegungen, die letztlich der Errichtung eines offenen und sicheren 
Arbeitsraums als notwendiger Grundlage der Kooperation dient. Weitere 
Themen zukünftiger Forschung auf dem technologischen Gebiet wären die 
Sicherheit der Datenflüsse, die Datenqualität und die Qualität der verwende- 


ten Komponenten wie Sensoren und Aktoren. Als aktuelle Forschungsfragen 
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auf dem Gebiet der Methoden werden die Entwicklung und Weiterentwick- 
lung von Referenzmodellen wie dem RAMI 4.0 genannt, insbesondere für 
die Beschreibung der Fähigkeiten eines Produktionssystems und deren Ver- 
wendung im Engineering und der Produktionsplanung. Auch auf dem Gebiet 
der Visualisierung verschiedenster Daten sehen Thoben, Wiesner und Wuest 
(2017) eine der aktuellen Herausforderungen, vor allem mit dem Ziel an der 
Schnittstelle zum Menschen diesem adäquate Entscheidungsgrundlagen zu 


liefern, nicht nur im Engineering. 


3.1.1 Cyber-Physische Systeme und kollaborative 
Robotik 


Einen Überblick über die aktuelle Forschung auf dem Gebiet der Mensch- 
Roboter-Kollaboration und dazu gehörige Klassifikationen und Begriffsdefi- 
nitionen geben X. V. Wang u.a. 2017. Angetrieben sei die aktuelle Entwick- 
lung von dem Wunsch nach einer sinnvollen Kombination der Fähigkeiten 
von Mensch und Maschine auf der einen und dem Ziel der flexiblen Pro- 
duktion und Wandelbarkeit der Anlagen auf der anderen Seite. Dabei sollen 
Routineaufgaben oder spezielle einzelne Schritte eher automatisiert werden, 
wohingegen lokale Entscheidungen oder Ausnahmesituationen nach mensch- 
lichen Fähigkeiten („human touch“) verlangen, um die gegebene Komplexität 
bewältigen zu können. Die Kombination von menschlichen und maschinellen 
Fähigkeiten, bei der weder Mensch und Roboter physisch voneinander ge- 
trennt sind noch Werker sich quasi als Teil der Automatisierung unterordnen 
müssen, verlangt auf dem Weg zu einer eher „symbiotischen Mensch-Roboter- 
Kollaboration“ nach einem höheren Maß an rechnergestützter Intelligenz 
(X. V. Wang u.a. 2017). Durch die stark gestiegene (potenzielle) Konnek- 
tivität aller Komponenten durch zahlreiche neue Kommunikationssysteme 
wie W-LAN, Bluetooth, NFC, etc. wird ein Nebeneinander von Werker und 


automatisierten maschinellen Elementen möglich, in dem die jeweiligen 
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Stärken sich ergänzen statt sich zu gegenseitig zu behindern (Monostori u.a. 
2016). 


Während Roboter ein hohes Maß an Präzision erreichen, große Massen 
bewegen können und sich hervorragend für häufig wiederkehrende Aufgaben 
eignen, erreichen sie schnell ihre Grenzen beim Erkennen und im Umgang mit 
unerwarteten Ereignissen, die nicht ihrer Programmierung entsprechen (X. V. 
Wang u.a. 2017). Mit solchen Situationen können Menschen im Allgemeinen 
wesentlich besser umgehen, da sie eine viel detailliertere Wahrnehmung 
der Umwelt und umfassendere Fähigkeiten haben. Auf der anderen Seite 
sind Menschen den Beschränkungen durch Irrtümer, Stress oder Müdigkeit 
ausgesetzt und ihr Einsatz unterliegt strengen Auflagen der Arbeitssicherheit 
(Arai, Kato und Fujita 2010). Nach Fong, Thorpe und Baur (2003) muss 
daher das Ziel sein, mit Technologien, die diese Differenzen überbrücken 
können, den Roboter als einen verlässlichen Kooperationspartner zu nutzen 
statt nur als möglicherweise gefährliches Werkzeug. Eine Übersicht und 
Klassifikation der verschiedenen Arten der Zusammenarbeit von Mensch 
und Roboter gibt Unterabschnitt 2.2.1 auf Seite 22. Bei Abweichungen 
vom geplanten Prozessablauf kann der Werker auf verschiedenen Ebenen 
eingreifen und reagieren, einen Überblick dazu gibt Abbildung 3.1. Von innen 
nach außen sind verschiedene Ebenen von Abweichungen vom geplanten 
Prozess dargestellt, die mit zunehmendem Einsatz, aber auch Risiko für den 
Werker verbunden sind. Sicherheitseinrichtungen sind häufig übergeordnet 
vorhanden und daher unabhängig von der Mensch-Roboter-Interaktion zu 
sehen (X. V. Wang u.a. 2017). 


Als systematischen Ansatz zur Konstruktion einer Umgebung für die Kolla- 
boration zwischen Mensch und Roboter definieren X. V. Wang u.a. (2017) 
eine „Serie von Analyse- und Syntheseschritten, beginnend mit einer for- 
malen Beschreibung der Aufgaben, Mittel und Voraussetzungen, auf dem 
Weg zu einer annehmbaren teilautomatisierten Lösung mit der Möglichkeit 


weiterer Iterationen und der Einführung von implizitem Wissen an Stellen 
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Zunehmende 


Geplanter Abweichung von der 
Prozess 


geplanten Nennwirkung 
und Gefahr für 
den Werker 


Ausnahmebehandlung und 
sofortige Fehlerbehebung 


Abweichung ohne sofortige 


Lebens- oder Gesundheitsgefahr 


Abweichung mit sofortiger 
Lebens- oder Gesundheitsgefahr 


Abbildung 3.1: Der Prozessbeschreibung entsprechende Nennwirkung und ihre schrittweise 
zunehmende Abweichung von der geplanten Nennwirkung mit den verschie- 
denen Eingriffsmöglichkeiten des Menschen und deren Risiko. Abbildung in 
Anlehnung an X. V. Wang u.a. (2017, S. 6). 


der manuellen Intervention in den Bearbeitungsprozess“. Eine besondere 
Rolle kommt dabei der Entwicklung der Sensoren und Datenverarbeitung zur 
Wahrnehmung des gemeinsamen Arbeitsraums von Mensch und Roboter zu. 
So kann zum Beispiel aus Daten von Kameras, die im Bereich des sichtbaren 
Lichts und im Infrarot-Bereich Daten liefern, über geeignete Kalibrations- 
und Filtermethoden die Lagebeziehung des Roboters zu Werkzeugen und 
Werkstücken berechnet werden (Rückert, Adam u.a. 2018). 


Einen umfassenden Überblick über die verschiedenen thematischen Teilberei- 
che der kollaborativen Robotik geben Krüger, Lien und Verl (2009). Neben 
den auch in Unterabschnitt 2.2.1 auf Seite 22 dargestellten verschiedenen For- 
men der Zusammenarbeit von Mensch und Roboter und deren Implikationen 
wurden von Krüger, Lien und Verl (2009) auch die organisatorischen und öko- 
nomischen Aspekte untersucht und dargestellt. In einer Fallstudie konnten sie 
die typische Verkürzung der gesamten Taktzeiten bei der Montage durch die 
kollaborative Montage nachweisen und auch den Bereich aufzeigen, in dem 


die kollaborative Montage als hybride Arbeitsform zwischen Handarbeit und 
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Vollautomatisierung ihre ökonomische Nische hat. In Abbildung 3.2 werden 
die Herstellungskosten pro Stück für die manuelle, die vollautomatisierte und 
die kollaborative Produktion in Abhängigkeit von der pro Jahr produzierten 
Stückzahl dargestellt. Im mittleren Bereich hat die kollaborative Montage 
das optimale ökonomische Profil (Krüger, Lien und Verl 2009). 


Kosten pro Einheit 


1.000 


Roboter Arbeitszelle 


100 


Vollautomatisierte Linie 
Manuelle Herstellung 


Manueller Arbeitsplatz Roboter Automatisierung 


0,1 


100 1.000 10.000 100.000 1.000.000 
Einheiten/Jahr 


Abbildung 3.2: Arbeits- und Automatisierungskosten in Relation zur hergestellten Stückzahl. 
Abbildung in Anlehnung an Krüger, Lien und Verl (2009, Abb. 40). 


Eine absolute Voraussetzung für die Zusammenarbeit zwischen Mensch und 
Roboter ist die Sicherheit des Werkers. Es existieren zahlreiche Ansätze und 
Forschungsarbeiten zu diesem Thema, an dem auch zahlreiche Institutio- 
nen (z. B. Berufsgenossenschaften) ein hohes Interesse haben. Die Wege zur 
Herstellung der Sicherheit umfassen zahlreiche Maßnahmen von der mecha- 
nischen Gestaltung des Roboters und Greifers bis zur Verwendung verschie- 
denster Sensoren zur Überwachung des gemeinsamen Arbeitsraums oder 
Kollisionserkennung. Die Forschung konzentriert sich aktuell ausschließlich 
auf die Zusammenarbeit eines Menschen mit einem Roboter. Krüger, Lien 
und Verl (2009) sehen eine der zahlreichen zukünftigen Herausforderungen 
auf diesem Gebiet darin die Zusammenarbeit mehrerer Menschen mit einer 


gemeinsamen Aufgabe durch einen Roboter zu unterstützen. 
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Die in Leitão u. a. (2016) vorgeschlagene und im PERFoRM-Projekt ange- 
wandte Architektur zielt darauf ab, Systeme möglichst einfach zu rekonfi- 
gurieren, indem der Plug-and-Produce-Ansatz mit den Eigenschaften des 
menschlichen Werkers kombiniert wird. Weiterhin sind Werkzeuge zur Pla- 
nung, Simulation und zur Entscheidungsunterstützung enthalten. Eine zentra- 
le Rolle in der von Leitäo u.a. (2016) präsentierten Systemarchitektur spielt 
eine Middleware, die die verschiedenen Systeme (MES, SCADA, etc.) und 
Assets (Roboter, SPS, etc.) durchgängig sicher, transparent und zuverlässig 
miteinander verbindet (siehe auch Abbildung 3.3). Dabei stellen die einzel- 
nen Komponenten ihre Funktionalitäten als Services zur Verfügung, die von 


anderen Komponenten erkannt und genutzt werden können. 


Legend: 


IT" Wrapper 


kun! 


== Standard 
Interface 
for Service 
| Technology 
Adaptor 


IT" Legacy Tool 


EB PERFORM tool 


Abbildung 3.3: PERFoRM Systemarchitektur. Quelle: Leitão u. a. (2016, S. 5732, Abb. 2). 


Zu den wichtigsten Aufgaben der Middleware gehören demnach neben der 
Unterstützung dieser Services auch die Sicherung der Performance, die Über- 
wachung des Datenaustauschs, die Umwandlung von Daten, die Sicherheit, 
die Ausnahmebehandlung und die Persistenz der Daten. Verschiedene Adap- 
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ter ermöglichen die Integration älterer Komponenten durch entsprechende 
Schnittstellen (Leitäo u.a. 2016, S. 5733). 


3.1.2 Kollaborationsgerechtes Informationsmanagement 


Bisher gibt es erst sehr wenige Arbeiten, die sich mit dem Informationsma- 
nagement bei der kollaborativen Montage beschäftigen und noch keine, die 
die Konsolidierung der Daten zum Ziel haben. Jedoch existieren grundlegen- 


de Arbeiten zum Design kollaborativer Prozesse (Saenz u.a. 2018). 


Einen Ontologie-basierten Ansatz zum Informationsmanagement bei der 
kollaborativen Montage schlagen Sadik und Urban (2017) vor. Dieser besteht 
aus einem Multi-Agenten-System, implementiert mit dem Java Agent Deve- 
lopment Environment (JADE), das mehrere selbständige Agenten verwaltet, 
die proaktiv, responsiv und sozial interagieren und aufgrund der ihnen zur 
Verfügung stehenden Informationen zum Beispiel Arbeitspläne generieren. 
Weiterhin gehört ein regelbasiertes System dazu, das neben den produktions- 
bezogenen Regeln auch den Aufbau und weitere Informationen der Anlage 
beinhaltet (Sadik und Urban 2017). 


Einen grundsätzlichen Konflikt sehen Böckenkamp u.a. (2017) zwischen der 
hierarchischen deterministischen Planung auf der einen und der maximalen 
Autonomie selbstorganisierender Systemkomponenten auf der anderen Seite. 
Letztere führt zu einer höheren Flexibiltät und Anpassungsfähigkeit der 
gesamten Anlage. Auch wenn die einzelne Komponente sich, allein schon 
aus Sicherheitsgründen, weiterhin deterministisch verhält, kann sich doch bei 
der Kooperation dieser Komponenten oder sogar einem Agieren als Schwarm 
ein nicht-deterministisches Verhalten ergeben. Das bei hoher Autonomität 
bestehende Risiko erheblicher Wartezeiten einzelner Komponenten ließe sich 
durch möglichst umfangreiche Fähigkeiten verringern. Ein anderer Ansatz 


zur zumindest teilweisen Auflösung dieses Konflikts könne auch eine nur 
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lokal und in zeitlich engen Fenstern bestehende Vorplanung der Ausführung 
sein (Böckenkamp u.a. 2017). 


Einen Cobot, der fast schon als humanoider Assistent anzusehen ist, stellen El 
Makrini u.a. (2017) auf der Basis eines Baxter Robots mit zwei Armen und 
einem Touchscreen vor. In einem exemplarischen kollaborativen Workflow 
ist er in der Lage, den durch Winken des Werkers signalisierten Beginn der 
Zusammenarbeit wahrzunehmen (Gestenerkennung). Anschließend ordnet er 
durch Gesichtserkennung dem Benutzer seinen Namen zu und spricht diesen 
über das Display mit Namen an. Mit einer Kamera und einer entsprechenden 
Bilderkennung assistiert er dann bei der Inspektion und korrekten Montage 
eines Werkstücks. Diese Schritte erlauben einen intuitiven Umgang mit dem 
Cobot und es sind zahlreiche weitere Anwendungen dieses Ansatzes in der 
Zukunft denkbar. 


Eine Methodik zur Einführung und Implementierung von Intelligent Manu- 
facturing Systems (IMS), besonders in kleinen und mittleren Unternehmen, 
stellen Cencen, Verlinden und Geraedts (2018) vor. Ein definierter Satz an 
Schritten von der Analyse bis zur Evaluation soll die Rekonfiguration kolla- 
borativer Systeme einerseits auf einen systematischen Ansatz bringen und 
andererseits vor allem eine schnelle Anpassung der Produktionssysteme an 
neue Produkte oder Produktvarianten erlauben. Bisher wurde der Ansatz noch 
nicht vollständig implementiert. Einen ähnlichen Ansatz zur systematischen 
Einführung von Cobots beschreiben Malik und Bilberg (2017). X. V. Wang 
u.a. (2017) stellen einen Rahmen zur Klassifizierung verschiedener For- 
men der Kollaboration, insbesondere auch unter Berücksichtigung mehrerer 


Menschen oder Roboter vor. 


Durch die zunehmende Verbreitung cyber-physischer Systeme im Industrie- 
4.0-Kontext wird die Automatisierungspyramide immer flacher und durch 
ein heterogenes Netzwerk miteinander kommunizierender Entitäten abgelöst 


(Ciavotta u. a. 2017). Eine IoT-Middleware zur Unterstützung der Simulation 
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(„Digitaler Zwilling“), insbesondere für kleinere Fabriken, stellen Ciavotta 
u.a. (2017) auf Basis von Microservices mit ihrem MAYA System vor. Ältere 
Systeme können hier mit Hilfe einer Verwaltungsschale angebunden werden 
(Adolphs u. a. 2016). 


Eine auf Apache Camel basierende und im Rahmen des PERFoRM Projekts 
entwickelte Middleware-Lösung für industrielle Komponenten, die jedoch 
nicht gezielt kollaborative Fälle anspricht, wurde von Gosewehr u. a. (2018) 
entwickelt. Das verwendete Informationsmodell basiert auf AutomationML 
und die OPC-UA-Anbindung erfolgt mit Hilfe von Eclipse Milo (siehe auch 
Abbildung 3.3). Einen ähnlichen Ansatz verfolgen Schel u.a. (2017) mit 
einem Manufacturing Service Bus (MSB), der die Anbindung von Kompo- 
nenten über zahlreiche Schnittstellen und Protokolle wie REST, OPC UA 
oder MQTT erlaubt. 


Einen Ansatz zur Entwicklung eines Human Machine Interface mit mobilen 
Endgeräten und auf Basis von OPC UA zeigen Gutierrez-Guerrero und 
Holgado-Terriza 2015 auf. 


In der Fallstudie von Pauker, Ayatollahi und Kittl (2014) wird für einen 
speziellen Robotertyp ein OPC-UA-Server und das entsprechende Infor- 
mationsmodell aufgebaut, um den Roboter anzusteuern. Die Kontrolle des 
Roboters kann von einem OPC-UA-Client aus erfolgen, der OPC-UA-Server 
wiederum steuert über die proprietäre Herstellerschnittstelle dann den Ro- 
boter (siehe auch Abbildung 3.4). Die Überwachung des Roboterzustands 
übernimmt der OPC-UA-Server und stellt so unter anderem sicher, dass kein 
Roboterprogramm gestartet werden kann, während der Roboter bereits eines 
ausführt. Zusätzlich wird auf der Seite des Informationsmodells einem be- 
sonderen Aspekt Rechnung getragen, nämlich der Wandelbarkeit der Zelle. 
Wechselt der Roboter den Greifer, wird dynamisch der entsprechende Teil 


des Informationsmodells geändert und die Eigenschaften und Methoden des 
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neuen Greifers werden über OPC UA zugänglich (Pauker, Ayatollahi und 
Kittl 2014). 


RobotStudio 


KS cell-controller 
Procedures 


l Gripper data OPC UA 
Controller OPC UA Server 


Procedures T £ 
ABB PC Interface S 


Gripper data 


Configuration 


Abbildung 3.4: Systemarchitektur mit OPC-UA-Server für ABB Roboter. Quelle: Pauker, 
Ayatollahi und Kittl (2014, S. 81, Abb. 5). 


3.1.3 Fähigkeitsbasierte Produktionsplanung 


Fähigkeiten sind ein relativ neuer Ansatz zur Modellierung von Produk- 
tionssystemen. Zur Herstellung eines Produkts sind einerseits bestimmte 
Fähigkeiten erforderlich und die zur Verfügung stehenden Ressourcen haben 
andererseits bestimmte Fähigkeiten. Eine Produktionsplanung, die darauf 
basiert diese beiden Mengen in mehr oder weniger deterministischer Art 


und Weise zusammenzubringen, nennt man fähigkeitsbasierte Produktions- 
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planung. Einen Ansatz zur Trennung der beteiligten Entitäten bietet das 
PPR-Modell, das zwischen Produkt, Prozess und Ressource unterscheidet 
(Cutting-Decelle u. a. 2007; Pfrommer, Schleipen und Beyerer 2013; Schlei- 
pen u.a. 2014): 


Produkt 
Ein Produkt kann ein Zwischenprodukt oder ein Endprodukt sein und es ist 
zu unterscheiden zwischen dem (abstrakten) Produkt-Typ und der konkreten 


Realisation eines einzelnen Exemplars des Typs. 


Prozess 

Ein Prozess beschreibt Änderungen an einem Produkt während der Produk- 
tion und umfasst verschiedenste Verfahren wie zum Beispiel Herstellung, 
Transport oder Montage. Aus der Menge aller Prozesse und ihrer möglichen 


Verbindungen ergeben sich mögliche Ausführungsplanungen. 


Ressource 

Als Ressource wird eine Entität (Hardware oder Software) bezeichnet, die in 
die Prozessausführung involviert ist, selbst aber nicht Teil des Produkts ist, 
also zum Beispiel Roboter, Maschinen oder Werkzeuge. Die Ressource und 


ihre Beziehungen zueinander bilden die Topologie eines Werks. 


Da noch keine einheitliche Definition besteht, schlagen Pfrommer, Schleipen 
und Beyerer (2013) die in Abbildung 3.5 dargestellte Semantik des Begriffs 
„Fähigkeiten“ („Skills“) auf der Basis des PPR-Konzepts vor. Aus der Menge 
der Prozesse („Schweißen“) ergibt sich in Verbindung mit den zur Verfügung 
stehenden Ressourcen eine konkrete Fähigkeit wie zum Beispiel „Gasschwei- 
Den auf Maschine 1“. In Verbindung mit einem konkreten herzustellenden 
Produkt kann aus den Fähigkeiten eine Folge von Aufgaben (,,Tasks“) ab- 


geleitet werden, z.B. „Schweißen der Teile 1 und 2 ergibt Teil 3“. Kommen 


51 


3 Stand der Wissenschaft und Technik 


konkrete Produktionsziele hinzu, können daraus Ausführungspläne abgeleitet 


werden. 


Prozesse 


Ressourcen >| Fähigkeiten 


Produkte > Aufgaben 


y 


poe +--+ 1 EE EEN 


| Produktionsziele (> Ausführungsplan | 


Abbildung 3.5: Fähigkeitsbasierte Produktionsplanung nach dem PPR-Modell. Abbildung in 
Anlehnung an Pfrommer, Schleipen und Beyerer (2013, Abb. 2). 


Daraus ergibt sich nach Pfrommer, Schleipen und Beyerer (2013) folgende 


Definition: 


Eine Fähigkeit (,,Skill“) ist das Vermögen einer Ressource ei- 
nen Prozess auszuführen. Fähigkeiten sind also die Verknüpfung 
zwischen Prozessen und Ressourcen, angereichert um zusätzli- 
che Informationen. (s. a. Abb. 3.5) 


Nach Haider (2013) ist ein „Asset“ eine Komponente, deren wirtschaftliche 
Lebensdauer größer als 12 Monate ist und die ihren Nutzen erhält durch 
die Bereitstellung von Diensten an Benutzer. Da die Begriffe „Skill“ und 
„Asset“ keine unmittelbare deutsche Entsprechung vergleichbarer Semantik 
haben, werden sie im folgenden nicht übersetzt, sondern als Fachbegriffe im 
englischen Original weiter verwendet. Ein fähigkeitsbasiertes Management 


der Assets schlagen Aleksandrov, Schubert und Ovtcharova (2014) vor mit 
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dem Ziel einer vertikalen Integration zwischen den Systemen höherer Ebene 
(wie Enterprise Resource Planning (ERP)) und den Systemen der Ausfüh- 
rungsebene. Der im Rahmen des Projekts SkillPro! entwickelte Ansatz ist in 
Abbildung 3.6 überblicksartig dargestellt. 


spezialisiert sich 


Skill ben 
A A hängt ab von 
benötigt implementiert 

Produkt-Skill Asset Skill 

Produkt Asset 

| definiert stellt zur Verfügung 

Produkt- Skill- 

anforderungen Randbedingungen 


Abbildung 3.6: Fähigkeitsbasierte Produktionsplanung nach dem SkillPro-Ansatz. Abbildung 
in Anlehnung an Aleksandrov, Schubert und Ovtcharova (2014, Abb. 2, S. 469). 


Er greift den Plug-and-Produce-Ansatz auf und erweitert ihn um alle Arten 
von Assets einschließlich menschlicher Arbeitskraft. Er bezieht neben der 
Ausführung auch die Schritte der Ausführungsplanung und mittel- und lang- 
fristige Aufgaben mit ein. Das Skill-Konzept ist eine logische Erweiterung 
des oben dargestellten PPR-Konzepts, indem es insbesondere drei verschie- 
dene Arten von Skills und deren Zusammenwirken definiert (Aleksandrov, 
Schubert und Ovtcharova 2014): 


‘http: //www.skillpro-project.eu 
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Skill 

Ein Skill ist eine abstrakte Darstellung für einen Prozess, der durch Metadaten 
(Parameter) spezifiert werden kann. Skills können hierarchisch strukturiert 
sein und somit Taxonomien aufbauen. Dabei gelten die Prinzipien der Verer- 
bung und speziellere Skills erben die Eigenschaften von weiter oben in der 


Hierarchie stehenden. 


Produktions-Skill 

Als Produktions-Skill wird die Zuordnung bestimmter Produktionsanforde- 
rungen für ein Produkt aufgrund seiner Eigenschaften bezeichnet. Er erfordert 
einen mit bestimmten Werten parametrisierten Skill, um die Produktionsan- 


forderungen zu erfüllen. 


Asset Skill 

Die Fähigkeit eines Assets, einen bestimmten Skill zur Verfügung zu stellen, 
nennen Aleksandrov, Schubert und Ovtcharova (2014) Asset Skill. Er imple- 
mentiert einen bestimmten Skill innerhalb der durch den Asset vorgegebenen 
Beschränkungen bei der Wahl der Parameter. Zusätzlich kann er Beziehungen 


zu anderen Skills als Vor- oder Nachbedingungen haben. 


Auf den Skills, die sequenziell oder parallel ausgeführt werden können, wer- 
den verschiedene Operationen wie das „skill matching“ oder die Kompo- 
sition zu zusammengesetzten Skills definiert. Weiterhin sieht das Skillpro- 
Framework verschiedene Teilsysteme zum Management der Skills vor, ins- 
besondere das Enterprise Management System (AMS), das Execution Man- 
agement System (EMS) und die Skill Execution Engine (SEE). 


Die Skills werden in diesem Kontext durch das AutomationML-Format be- 
schrieben und kommuniziert, in dem auch die Assets beschrieben sind und 
ihre Daten und Fähigkeiten über entsprechende OPC UA Objektstrukturen 
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anderen zur Verfügung stellen, so dass sie durch die Verbindung aus phy- 
sischer Struktur und virtueller Abbildung cyber-physische Systeme bilden 
(Pfrommer, Stogl u.a. 2014; Schleipen u.a. 2014). Die im Skillpro-Projekt 
verwendeten Arten von Skills und ihre Beziehungen zueinander fasst Abbil- 


dung 3.7 zusammen. 


Produkt Skill Asset 


—> Produktions-Skill «—\—>} Asset Skill I. — 


_——>| Ausführbarer Skill }«— 


Abbildung 3.7: Im Skillpro-Projekt verwendete Arten von Skills. Abbildung in Anlehnung an 
Pfrommer, Stogl u. a. (2014, Abb. 1). 


Verknüpft werden die so modellierten Assets und Skills durch drei Manage- 
mentteilsysteme (siehe auch Abbildung 3.8), die gemeinsam für Planung und 
Ausführung der Skills sorgen und über OPC UA miteinander kommunizieren 
(Pfrommer, Stogl u.a. 2014). Das Asset Management System (AMS) bildet 
die Wissensbasis des Unternehmens in Bezug auf die Produktion und führt 
Produktions-Skills und Asset Skills zusammen, so dass daraus ausführbare 
Skills generiert werden können. Diese können dann vom Manufacturing 
Execution System (MES) koordiniert und zu einem Ausführungsplan zusam- 
mengestellt werden, der mehrere Assets beinhalten kann und vom aktuellen 
Zustand der Assets abhängt. Dazu steht das MES mit (typischerweise) meh- 


reren Skill Execution Engines in Kontakt, die eine Art Verwaltungsschale um 
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die Assets bilden und ein einheitliches Interface anbieten (Pfrommer, Stogl 
u.a. 2014) (siehe auch Abbildung 3.8). 


Abbildung 3.8: Skillpro Systemarchitektur. AMS: Asset Management System, MES: Manufac- 
turing Execution System, SEE: Skill Execution Engine. Abbildung aus Pfrom- 
mer, Stogl u. a. (2014, Abb. 2). 


Einen ebenfalls skill-basierten Ansatz zur Fertigungsplanung in Verbindung 
mit einem Optimierungsmodell verfolgen Storms u.a. (2017). Drei alter- 
native Ansätze zur Zuordnung zwischen Ressource und Aufgabe stellen 


Blankemeyer u. a. (2019) gegenüber. 


3.1.4 Anwendung und Kombination von Standards 


Aktuelle Standards zur Kommunikation und Datenmodellierung sind nicht 
nur selbst Gegenstand der Forschung, sondern auch ihre Anwendung für 
neue Fragestellungen und mögliche Kombinationen. Eine in diesem Kontext 
große Rolle spielen AutomationML und OPC UA, deren Grundlagen bereits 
in Abschnitt 2.4 erläutert wurden. Henßen und Schleipen (2014) beschrei- 


ben einen Ansatz zur gemeinsamen Nutzung beider Protokolle durch die 


56 


3.1 Stand der Forschung 


Identifikation von Analogien und Ableitung einer Methode zur Generierung 
eines OPC UA Datenmodells aus einer vorliegenden Anlagenbeschreibung 
in AutomationML. Dies soll vor allem den am Anfang der Nutzung von OPC 
UA hohen Aufwand für die Entwicklung des Datenmodells verringern, indem 
aus den offline vorhandenen Daten ein Kommunikationsmodell abgeleitet 
wird. Diese liegen im Idealfall geschlossen und umfassend in AutomationML 
vor, können jedoch im weniger günstigen Fall auch auf mehrere Quellen ver- 
teilt sein. Da beide Standards einen objektorientierten Ansatz haben und auf 
dem Typ-Instanz-Prinzip beruhen, können einige Analogien ausgenutzt und 
darauf Zuordnungen definiert werden. Aus der hierarchischen Baumstruktur 
von AutomationML kann eine ebenso hierarchische OPC UA Datenstruktur 
abgeleitet werden, obwohl dies nur ein Spezialfall der in OPC UA grund- 
sätzlich möglichen Netzstrukturen und damit eine bewusste Einschränkung 
ist. Die trotz aller Ähnlichkeiten bestehenden Unterschiede zwischen den 
beiden standardisierten Modellen können durch Definition eigener OPC UA 
Typen (wie zum Beispiel ,,HasAMLChild“) überbrückt werden (Henßen 
und Schleipen 2014). Dazu existiert bereits ein automatischer Konverter von 
AutomationML zu OPC UA?. 


Die Produktion einer Vielzahl von Varianten eines Produkts erfordert die 
häufige Umrüstung und Rekonfiguration von Anlagen, bei der möglichst 
geringe Aufwände entstehen sollen. Einen wichtigen Beitrag dazu kann das 
Konzept der Verwaltungsschale liefern, das eine informationstechnische Kap- 
selung jeder Komponente einschließlich einer Abstraktion ihrer Fähigkeiten 
auf ein herstellerunabhängiges und für andere Komponenten semantisch 
verarbeitbares Niveau vorsieht (Hankel 2015). Einen Ansatz zu einer sol- 
chen „Plug and Produce“-Lösung stellen Profanter u. a. (2017) vor. Demnach 
besteht eine solche Umgebung aus einem OPC UA Discovery Service in 
Verbindung mit einer hierarchischen Architektur und einem Manufacturing 


Service Bus (MSB), der neue Komponenten bemerkt und ihre Konfiguration 


? https: //aml2ua.iosb.fraunhofer.de/ 
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automatisiert erledigt. Die einzelnen Komponenten sind von einer Verwal- 
tungsschale „umgeben“ und die Kommunikation findet auf Basis von OPC 
UA statt. (siehe auch Abbildung 3.9). 


Manufacturing Service Bus 
"EE Server 


Network Layer 1 


Workstation 1 Workstation 2 
SPC Server PC Server 


| Network Layer 2 | Network Layer 2 


Device 1.1 Device 1.2 Device 2.1 Device 2.2 
"EE Server H #9PC Server PC Server H PC Server 


Abbildung 3.9: Plug-and-Produce-Architektur mit Manufacturing Service Bus. Abbildung aus 
Profanter u.a. (2017, Abb. 2). 


Die zentrale Rolle in dieser Architektur spielt der Manufacturing Service 
Bus, der OPC UA Local Discovery Server mit Multicast Extension (LDS-LE) 
implementiert und alle Informationen tiber im Netzwerk vorhandene Assets 
bereithält und gleichzeitig entsprechend auf neu verbundene reagiert. Damit 
verwandelt sich die Automatisierungspyramide in eine mehr oder weniger 
flache horizontal und vertikal integrierte Automationsplattform (Profanter 
u.a. 2017). OPC UA stellt verschiedene Dienste zur Verfügung, die mehr 
oder weniger flexibel das Hinzufügen und Verwalten neuer Server erlauben. 
Bei der Multicast Extension senden neu hinzugefügte Hosts per Multicast 
eine Ankündigung und werden dann vom Discovery Server registriert, so dass 
keine festen IP Adressen oder ähnliche Daten vorgegeben werden müssen 
(OPC Foundation 2015). Profanter u.a. (2017) verwenden zur Evaluation 


eine eigene Implementierung des Local Discovery Servers mit Multicast 
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Extension auf Basis des Open Source Eclipse Projekts Milo? als Framework, 


das auch in der vorliegenden Arbeit Verwendung findet. 


Einen pragmatischen Ansatz zur Kapselung der Robotersteuerung in OPC 
UA zeigen Brecher u.a. (2017) auf. Dabei werden die Zustände und Fä- 
higkeiten eines Roboters, hier des UR 5 von Universal Robots, auf Socket- 
bzw. Modbus-Ebene von einem von der eigentlichen Robotersteuerung ge- 
trennten Rechner angesprochen, der gleichzeitig als OPC-UA-Server fungiert 
und aufgrund des entsprechend modellierten Informationsmodells alle Ro- 
boterzustandsdaten und -fähigkeiten einem OPC-UA-Client zur Verfügung 
stellt, so dass eine übergreifende und von der speziellen Implementierung 


unabhängige Möglichkeit der Ansteuerung des Roboters entsteht. 


3.1.5 Virtuelle Absicherung und Simulation der Montage 


Zahlreiche Möglichkeiten ergeben sich, wenn sowohl das Produkt als auch 
die Produktionsanlage modellhaft digital dargestellt werden („Digitaler Zwil- 
ling“). Einen Ansatz zur teilweise automatisierten Planung und Roboter- 
steuerung auf Basis von Simulationen zeigen (Roggendorf u. a. 2019) auf. 
Insbesondere werden hier Greiferpositionen und -zustände und die Bewe- 
gungsbahnen des Roboterarms in Verbindung mit Expertenwissen geplant. 
Eine verbreitete Möglichkeit zur Programmierung von Robotern ist das Be- 
wegen des Roboters zum Lernen der dann später selbständig durchgeführten 
Bewegungen („Teaching“). Wird dieses Lernen nicht am Roboter selbst voll- 
zogen, sondern innerhalb einer Simulation, die mit Hilfe geeigneter Geräte in 
die eigentliche Arbeitsumgebung eingeblendet wird (,,Augmented Reality“), 
ergeben sich daraus zahlreiche Vorteile, wie Rückert, Meiners und Tracht 
(2018) zeigen. Das verwendete System fasst Abbildung 3.10 auf der nächsten 


Seite zusammen. Im Mittelpunkt steht dabei ein Controller, der die erzeugten 


’https://github.com/eclipse/milo 
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Daten erfasst, speichert und dem Roboter zur Verfügung stellt und gleich- 
zeitig auch die Schnittstelle für den Werker bildet. Die AR Geräte und die 
Simulation sind nicht mehr erforderlich, nachdem die Roboterprogramme 


erzeugt wurden. 


Physical Robot Simulation Station Controller 

Virtual Twin Database Interface DB 
8 = ; 8 
Š 2 | Assembly Plan Sequencing Logic 
E 8 Assembly Plans 
5 2 
8 š 

S 

Coordinates Hardware Controller 
Augmented Reality Device Robot Coordinates 


User GUI 


Worker Data 


Administrator GUI 


Abbildung 3.10: Systemarchitektur mit Station Controller und physikalischer Roboter- 
Simulation. Abbildung aus Rückert, Meiners und Tracht (2018, Abb. 2). 


Einer solchen virtuellen Absicherung durch Simulation kommt bei kollabora- 
tiven Prozessen eine besondere Bedeutung zu, da sie einen wichtigen Beitrag 
zur Herstellung und Aufrechterhaltung der Sicherheit des Werkers liefern 
kann. Einen Weg zur Implementierung unter Berücksichtigung der Eignung 
verschiedener Ein- und Ausgabegeräte skizzieren Rückert, Wohlfromm und 
Tracht (2018). 
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3.1.6 Persistierung und Rückführung von Prozess- und 
Qualitätsdaten in Planung und Konstruktion 


Eine „lebenszyklusorientierte Prozesskettenplanung“ schlagen Labbus u.a. 
(2017) anhand eines Fallbeispiels aus der Automobilindustrie vor. Mithilfe 
des Standards zur Anlagenbeschreibung AutomationML wird schon bei der 
Planung der Einsatz mehrerer Werkzeuge und die einfache Weitergabe der 
Planungsdaten ermöglicht. Diese können bei der Inbetriebnahme unmittelbar 
(eventuell teilweise automatisiert mit einem Konverter*) in ein OPC-UA- 
Datenmodell überführt werden, das die Anlagensteuerung und die Erfassung 
von Zustandsdaten über OPC-UA-Verbindungen ermöglicht. Beim Betrieb 
werden zusätzlich Anlagendaten in einen Data Lake persistiert, die dann 
später wieder zu Planungszwecken herangezogen und ausgewertet werden 
können (siehe Abbildung 3.11). 


8 AutomationML 1 Konzept-/Detail O 2 AutomationML 

* Anlagen- und /SM-Too + Anlagen- und 
Prozessbeschreibung mum Prozessbeschreibung 

* Anlagentopologie + Anlagentopologie 


* Referenzdaten 


I "A ý 
7 9 = » 6 


Datenbereitstellung Data Lake Beschaffung und 
* Betriebs-, Maschinen-, (Semi-Strukturiert) Inbetriebnahme 
Energiedatenerfassung — * Konstruktion 
+ Vorverarbeitung erfasster OPC UA + SPS-Programmierung 
Daten Online Datenerfassung * Inbetriebnahme 
- | 
a 
6 OPC UA > Betrieb 4 OPC UA 
* Identifikation anhand der + SPS-Programme 
Anlagenbeschreibung um em fr, OPC UA Profil analog 
+ Online Datenerfassung Gegenstand Anlagentopologie 
(Maschine) + Anlagenbeschreibung 


Abbildung 3.11: Integriertes Gesamtkonzept zur Datenbereitstellung. Abbildung aus Labbus 
u.a. (2017, Abb. 3, S. 542). 


*nttps://aml2ua.iosb.fraunhofer.de/ 
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3.2 Stand der Technik in der Industrie 


Die im vorherigen Kapitel dargestellten Forschungsarbeiten und -ergebnisse 
sind in den meisten Fällen bisher nur in prototypische Implementierungen 
eingeflossen, von einer weiten Verbreitung dieser Ansätze in der Industrie 
kann keine Rede sein. Die Studie von Bauer, Bender u. a. (2016) mit dem 
Untertitel „Erste Erfahrungen von Anwenderunternehmen“ kommt u.a. zu 


den folgenden Ergebnissen: 


e Es gibt bisher kaum kollaborative Anwendungsfälle in laufender Pro- 
duktion. 


e Überwiegend arbeiten Werker und Roboter in Koexistenz (vgl. Kapi- 


tel 2.2.1) nebeneinander. 


e Neben dem Hauptziel, der wirtschaftlichen Optimierung, werden Ro- 


boter auch zur Verbesserung der Ergonomie eingesetzt. 


e Der Aufwand zur Aufrechterhaltung der Sicherheit wird offenbar sys- 


tematisch unterschätzt. 


Auch in den drei mittelgroßen Anwenderunternehmen aus der Industrie, 
die im Rahmen des KoKoMo-Projekts prototypisch einen kollaborativen 
Montage-Arbeitsplatz umgesetzt haben, waren diese die ersten derartigen 


Arbeitsplätze im Unternehmen. 


Die von Kadir, Broberg und Conceição (2018) unter diesem Aspekt unter- 
suchten Unternehmen hatten vor der Studie wenig oder keine Erfahrungen 
mit kollaborativer Robotik. In Interviews mit verschiedenen Akteuren zu 
zentralen Themen des Einsatzes von Cobots zeigt sich, dass die Inbetrieb- 
nahme mit nur mäßigem Aufwand verbunden war, die Werker sich sicher 


fühlten und ihnen sich wiederholende Arbeitsabläufe abgenommen werden 
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konnten, aber der richtige Einsatz, auch unter ökonomischen Aspekten, die 


entscheidende Herausforderung zu sein scheint. 


Auch die durchgängige Nutzung aller zur Verfügung stehenden Daten als 
Grundlage einer modernen Anlagenplanung und -nutzung ist in der Industrie 
keinesfalls Standard. Trost (2015) cit. in Schleipen (2018, S. 56) zeigt sogar 
erheblichen Nachholbedarf, denn etwa 40 % der befragten Unternehmen 
berichteten von einer nur unzureichenden Datenqualität und in 60 % der 
Betriebe sind die Verantwortlichen mit den Kennzahlen unzufrieden, fast 
die Hälfte hat im Unternehmen schlichtweg keine. 20-30 % der geplanten 
Produktionsprozesse werden kurz vor Beginn noch geändert wegen Maschi- 
nenfehlfunktionen oder unvorhersehbaren Konflikten (Schleipen 2018, S. 56). 


Diese Prozesse wurden also offensichtlich auch nicht simuliert. 


Eine im Jahr 2018 durchgeführte Umfrage zum Stand der Umsetzung von 
IloT-Projekten in der deutschen Industrie (IDC Central Europe 2018) ergab, 
dass in der Fertigungsindustrie 23 % aller Unternehmen bereits entsprechen- 
de Projekte umgesetzt haben, im Maschinen- und Anlagenbau sogar 26 %, 
in der öffentlichen Verwaltung waren es nur 7 %. Als Hindernisse bei der 
Umsetzung wurden von den Unternehmen unter anderem genannt die hohe 
Komplexität, der Mangel an Softwaresicherheit und eine ungeeignete Infra- 
struktur. Von 15 % der befragten Unternehmen wurden auch Unklarheiten 
über den Kundennutzen als entgegenstehende Bedingung genannt. Rund ein 
Drittel der Unternehmen will bis Ende 2018 ein IIoT-Lab, also eine geschütz- 
te Umgebung zum Testen von HoT-Projekten und -Prototypen, einrichten. 
Auch hier sind die Fertigungsunternehmen und die Maschinen- und Anla- 
genbauer deutlich weiter vorne als die übrigen Branchen. Chance und Risiko 
gleichzeitig sehen die Analysten von IDC (IDC Central Europe 2018) bei 


den noch fehlenden einheitlichen Standards zur Integration. 


Bei einem genaueren Blick auf die Form der Mensch-Roboter-Kollaboration 


in 25 Anwendungsfällen aus der Industrie, die das Fraunhofer Institut für 
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Arbeitswirtschaft und Organisation im Jahr 2016 näher untersucht hat, fällt 
auf, dass die echte Kollaboration offenbar recht selten vertreten ist (siehe 
Abbildung 3.12). Die Definition und nähere Erläuterung der einzelnen Inter- 
aktionsformen ist in Unterabschnitt 2.2.1 auf Seite 22 zu finden. 


Grad der Kollaboration 


m Zelle 

E Koexistenz 
Synchronisation 

® Kooperation 

=Œ Kollaboration 


Abbildung 3.12: Grade der Kollaboration in 25 Anwendungsfällen aus der Industrie. Abbil- 
dung aus Bauer, Bender u. a. (2016, Abb. 19, S. 39). 


Mit einem Anteil von 60 % an den untersuchten Anwendungsfällen dominiert 
die Koexistenz, das heißt es gibt keinen gemeinsamen Arbeitsraum von 
Mensch und Roboter, aber im Gegensatz zur Zelle gibt es keinen Schutzzaun. 
Die zweithäufigste Art der Zusammenarbeit ist die synchronisierte mit 16 %, 
bei der Mensch und Roboter zwar einen gemeinsamen Arbeitsraum haben, 
sich in diesem aber nicht zur selben Zeit bewegen. Die echte Kollaboration, 
bei der Mensch und Roboter gemeinsam zur selben Zeit im gemeinsamen 
Arbeitsraum am selben Werkstück arbeiten, ist mit 8 % der Fälle nur relativ 
selten vorzufinden (Bauer, Bender u.a. 2016, S. 39). 


Der „Gartner Hype Cycle for Emerging Technologies“ (siehe Abbildung 3.13) 
wird jährlich vom Marktforschungsunternehmen Gartner erstellt und geht da- 
von aus, dass die Einführung einer neuen Technologie in fünf Phasen verläuft, 


die sich durch die wechselnden Erwartungen mit Ablauf der Zeit unterschei- 
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den: Nach der Innovation folgt der Gipfel überzogener Erwartungen, dann 
das Tal der Desillusionierung, der Anstieg der „Erleuchtung“ und als fünfte 
Phase das Plateau des produktiven Einsatzes einer neuen Technologie. Das 
Thema „Smart Robots“ sieht Gartner im Bereich des Gipfels der überzogenen 
Erwartungen, vom Erreichen des Plateaus des produktiven Einsatzes wird 


von Gartner in 5 bis 10 Jahren ausgegangen. 


Hype Cycle for Emerging Technologies, 2018 
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Abbildung 3.13: Gartner Hype Cycle for Emerging Technologies 2018, hier relevant „Smart 
Robots“. https://www.gartner.com/smarterwithgartner/5-trend 
s-emerge-in-gartner-hype-cycle-for-emerging-technologie 
s-2018/ (abgerufen am 10.12.2019). 


3.3 Zusammenfassung 


Auf dem Weg zur Smart Factory mit der Losgröße 1 und teilweise kollabo- 


rativ erledigten Aufgaben sind in der Forschung schon zahlreiche Schritte 
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gemacht wurden, während die Umsetzung in der Praxis in vielen Unterneh- 
men noch zögerlich und lückenhaft bleibt. Als generelle Forschungsaufgaben 
stehen aktuell die Aufgabenplanung für kooperative Systeme, die Persistie- 
rung, Darstellung und Analyse fertigungsbezogener Informationen, aber auch 
die Gewährleistung der Sicherheit und ökonomische Fragen im Raum. Auf 
dem Gebiet des Informationsmanagements wird die klassische Hierarchie 
der Automatisierungspyramide immer weiter aufgelöst. An ihre Stelle treten 
vernetzte Systeme ohne oder mit flacher Hierarchie. Dabei zeigten sich in 
vielen Projekten und Fallstudien die Vorteile einer zentralen Instanz, die 
zwischen den heterogenen Einzelsystemen für einen durchgängigen Informa- 
tionsfluss sorgt. Dies kann beispielsweise ein Manufacturing Service Bus, ein 
Integration Bus oder auch eine ähnliche Lösung auf Basis einer geeigneten 
Middleware sein. Im Zusammenwirken zwischen cyber-physischen Syste- 
men und menschlichen Werkern gilt es immer wieder die jeweiligen Stärken 
im Prozess zu nutzen, zum Beispiel die Präzision auf der einen und die Fä- 
higkeit zu komplexen Reaktionen auf der anderen Seite. Aus ökonomischer 
Sicht füllt die kollaborative Montage die Lücke zwischen rein manueller 
Arbeitsweise und (Voll-)Automatisierung mit hohen Anfangskosten, die sich 
erst bei hohen Stückzahlen angemessen früh amortisieren. Informationsflüs- 
se, die auf aktuellen Standards wie AutomationML und OPC UA basieren, 
haben sich schon in einigen Forschungsprojekten bewährt, wenn auch noch 
viele Detailfragen ungeklärt sind. Ein ebenfalls aktueller Ansatz zur Arbeits- 
planung ist die fähigkeitsbasierte Produktionsplanung, die durch Finden von 
Übereinstimmungen zwischen den vorhandenen Fähigkeiten verschiedener 
Produktionsmittel und den zur Herstellung eines Produkts benötigten Fä- 
higkeiten automatisiert einen Plan erstellt. Auch zur virtuellen Absicherung 
der Produktionsplanung durch Simulation gibt es bereits Ansätze, die da- 
mit nicht nur einen Beitrag zur Sicherheit, sondern auch zu ökonomischen 
Betrachtungen liefern. Im Interesse aktueller Forschung stehen Ansätze zur 


adäquaten Persistierung aus der Produktion gewonnener Daten und deren zu 
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Zwecken der Überwachung und (Re-)Konfiguration geeignete Analyse und 
Darstellung. 
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In den vorhergehenden Kapiteln wurden die Grundlagen moderner industri- 
eller Kommunikationsverfahren und der aktuelle Stand der Wissenschaft und 
Technik auf Basis einer umfangreichen Literaturrecherche dargestellt. Die 
darauf aufbauend im folgenden vorgestellte Methodik hat zum Ziel, durch 
effiziente Informationsflüsse die kollaborative Montage für alle Akteure zu 
vereinfachen und gleichzeitig wirtschaftlich attraktiver zu gestalten. Sie be- 
steht aus mehreren Teilbereichen, die durch die gemeinsame Nutzung einer 


Integrationsinfrastruktur (‚Integration Bus“) miteinander verbunden sind. 


Nach der Entwicklung der Anforderungen an ein ganzheitliches Informa- 
tionsmanagement für die kollaborative Montage im folgenden Abschnitt 
wird in Abschnitt 4.2 der Einsatz einer zentralen Integrationsplattform als 
verbindendes Element der einzelnen Teillösungen vorgestellt. Hier werden 
die heterogenen Informationsquellen und -ziele miteinander verbunden und 
sie bildet daher einen wesentlichen Baustein der Methodik, der letztlich auch 
das Ziel eines Kreislaufs im Sinne einer iterativen Optimierung von Produkt 
und Anlage ermöglicht. Auf diesen Kreislauf wird dann näher in Abschnitt 
4.3 eingegangen, das nicht nur den Lebenszyklus von Produkt und Anlage 
beschreibt, sondern auch insbesondere die Rolle der Simulation als virtu- 
elle Absicherung in den Fokus stellt. Die Ansteuerung der kollaborativen 


Zelle mit ihren Akteuren Mensch und Roboter (Cobot) und ihren speziellen 
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Herausforderungen beschreibt der Abschnitt 4.5, in dem auch ein zu die- 
sem Zweck entwickeltes Datenmodell und -format vorgestellt wird, das eine 
auf den kollaborativen Fall zugeschnittene Formulierung von Arbeitsplänen 
unterstützt. Deren Ausführung wiederum muss die Details der Synchronisa- 
tion von Cobot und Mensch ermöglichen, die sowohl sequenziell als auch 
parallel oder auch unabhängig voneinander aktiv sein können. Die bei der 
Montage, gleichgültig ob real oder simuliert, entstehenden Prozessdaten und 
ihre Nutzung sind Gegenstand der beiden folgenden Kapitel. Sie können 
einerseits im Sinne eines Monitoring beobachtet und auch in Echtzeit aus- 
gewertet werden, andererseits aber auch für die spätere Analyse persistiert 
und in geeigneter Weise zur Verfügung gehalten werden, was in Abschnitt 
4.6 näher betrachtet wird. Dabei wird bei dem hier beschriebenen Ansatz 
durchgängig auf aktuelle Verfahren und Standards wie OPC UA aufgebaut. 
Das Monitoring und die spätere Analyse der Prozessdaten insbesondere im 
kollaborativen Fall hat Abschnitt 4.7 zum Inhalt. Mit Hilfe verschiedener 
Werkzeuge werden „Big Data“ in „Smart Data“ überführt, die also wertvolle 
Informationen über zurückliegende Montage-Schritte liefern und damit die 
Optimierung zukünftiger Produktion ermöglichen. Damit schließt sich der 
oben angesprochene Kreis des Informationsflusses bei der kollaborativen 


Montage. 


4.1 Entwicklung der Anforderungen 


Die meisten Fragestellungen, die sich bei der Gestaltung des Prozess- und 
Informationsmanagements der kollaborativen Montage ergeben, sind auch 
bei anderen nicht-kollaborativen Formen der Montage bekannt. Von der Idee 
über das Engineering, die verschiedenen Herstellungsschritte, den Verkauf 
bis hin zum Recycling durchläuft ein Produkt zahlreiche Phasen. Das Product 
Lifecycle Management (PLM) ist ein seit Jahren bekanntes, aber in vielen 


produzierenden Unternehmen noch nicht oder nur teilweise umgesetztes 
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Konzept. Eine Definition dieses Konzepts bilden die sog. „Liebensteiner 
Thesen“ (Sendler 2009, S. 27f): 


PLM ist ein Konzept, kein System und keine (in sich abgeschlossene) 


Lösung. 


Zur Umsetzung/Realisierung eines PLM-Konzeptes werden Lösungs- 
komponenten benötigt. Dazu zählen CAD, CAE, CAM, VR, PDM und 


andere Applikationen für den Produktentstehungsprozess. 


Auch Schnittstellen zu anderen Anwendungsbereichen wie ERP, SCM 
oder CRM sind Komponenten eines PLM-Konzeptes. 


PLM-Anbieter offerieren Komponenten und/oder Dienstleistungen zur 


Umsetzung von PLM-Konzepten. 


In diesem Rahmen soll sich auch die hier vorgestellte Methodik bewegen, 
die einzelne Teile eines für die kollaborative Montage geeigneten PLM- 
Konzeptes beinhaltet, die einerseits so generisch sind, dass sie nicht nur in 
einem speziellen Unternehmen eingesetzt werden können und an anderer 
Stelle wiederum so spezifisch sind, dass sie die spezielle Form der Montage 
in der Kollaboration von Mensch und Roboter mit darauf zugeschnittenen Me- 
thoden unterstützt. Daher werden einige allgemein gültige PLM-Aspekte hier 
ausgeklammert oder nur am Rande behandelt und stattdessen das Hauptau- 


genmerk auf die kollaborative Montage variantenreicher Produkte gelegt. 


Kollaborative Prozesse erfordern umfassende und präzise Kontextbeschrei- 
bungen für die Interaktion von Mensch und Roboter, auch vom Informa- 
tionsmanagement einen Beitrag zur Absicherung der Inbetriebnahme und 
Aufrechterhaltung der Sicherheit und ein umfassendes Konzept zur Erfassung, 
Speicherung und Analyse der Prozessdaten. Dies alles ist Voraussetzung für 
ein variantenreiches Produktspektrum und die damit erforderlich werdende 


Flexibilität bei der Anpassung der Anlagen. 
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Aber nicht nur das eigentliche Produkt, sondern auch die Anlage, mit deren 
Hilfe es hergestellt wird, hat einen Lebenszyklus und assoziierte Daten, ist 
sogar selbst ein Produkt, zum Beispiel aus der Sicht des Maschinenbauers. 
Zwischen dem Lebensweg des eigentlichen Produkts und dem der es produ- 
zierenden Anlage gibt es Beziehungen, die umso enger sind, je spezifischer 
die Anlage auf ein einzelnes Produkt zugeschnitten ist. Die Vorteile der 
kollaborativen Montage aber entfalten sich insbesondere bei der Herstellung 
kleiner Serien und variantenreicher Produkte, weshalb die Anlage im Rahmen 


der Möglichkeiten allgemein und nicht zu produktspezifisch sein sollte. 


Im Einzelnen können daraus die folgenden fünf Anforderungsbereiche an ein 


Informationsmanagement für die kollaborative Montage abgeleitet werden: 


1. Digitaler Zwilling von Anlage und Produkt 

2. Arbeitsplan und Steuerung (virtuell und real) 

3. Persistierung der Prozessdaten 

4. Kollaborationsspezifische Analyse der Prozessdaten 


5. Monitoring der kollaborativen Prozesse 


Digitaler Zwilling 

Es bietet mehrere Vorteile, alle an der Montage beteiligten physisch exis- 
tierenden Objekte, insbesondere Produkt und Anlage, vollständig digital 
abzubilden. Dieses Abbild wird auch als „Digitaler Zwilling“ bezeichnet. 
Dazu gehören nicht nur die geometrischen Eigenschaften, sondern auch 
die Kinematik und alle weiteren bei der Montage relevanten Informationen. 
Auf Basis dieses digitalen Zwillings, also der virtuellen Repräsentation von 
Produkt und Anlage, können verschiedene Schritte der Planung optimiert 
und vollständig überprüft werden, bevor die eigentliche physische Montage 
stattfindet. Dazu gehört der Test der Anlagenkonstruktion, der Ablauf der 
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Montage, aber auch die Detektion problematischer Zustände und Ereignisse 
wie zum Beispiel Kollisionen zwischen Werker und Roboter, die zu Verlet- 
zungen führen könnten. Die virtuelle Absicherung und Inbetriebnahme durch 
Simulation sind also weitere wichtige Schritte, die der digitale Zwilling erst 
ermöglicht. Gerade mit dem Ziel der flexiblen Adaption der Anlage an ein 
breites Spektrum von Produktvarianten sind diese Möglichkeiten essenti- 
ell. 


Die Anforderungen an ein die interaktive kollaborative Montage unterstützen- 
des Informationsmanagement umfassen also die Erfassung und Speicherung 
aller Facetten des digitalen Zwillings von Produkt und Anlage. Weiterhin sol- 
len diese Daten adäquat zugreifbar und für die Simulation und die Konstruk- 
tion zur Verfügung gestellt werden. Dabei muss ein geeignetes Datenmodell 
verfügbar sein, aus dem weitere erforderliche Datenmodelle, zum Beispiel 
zur Unterstützung der Kommunikation zwischen Steuerung und simulierter 


oder realer Zelle, generiert werden können. 


Arbeitsplan und Steuerung 

Mit dem Produktvariantenreichtum entsteht auch der Bedarf einer flexiblen 
Anpassung des Arbeitsplans an verschiedene Montagesituationen. Die Erstel- 
lung von Arbeitsplänen kann manuell, teilautomatisiert oder auch vollständig 
automatisiert erfolgen, zum Beispiel auf der Basis bekannter Fähigkeiten der 
Assets und erforderlicher Fähigkeiten zur Montage einer bestimmten Produkt- 
variante. Dieser Weg der fähigkeitsbasierten Arbeitsplanung wurde bereits 
umfassend untersucht (Aleksandrov, Schubert und Ovtcharova 2014; Pfrom- 
mer, Stogl u.a. 2014; Schleipen u. a. 2014), so dass er hier ausgeklammert 
werden soll. Stattdessen liegt der Fokus der hier beschriebenen Methodik 
auf der Ausführung eines bereits existierenden Arbeitsplans unter beson- 
derer Berücksichtigung der sich für die kollaborative Montage ergebenden 


Fragestellungen und aktueller Industriestandards. 
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Daraus ergibt sich als Teilanforderung die Möglichkeit der Speicherung von 
Arbeitsplänen in einem auf die speziellen Anforderungen der kollaborativen 
Montage abgestimmten Datenmodell und -format. Bei der Steuerung des 
Montageablaufs in der realen oder virtuellen Anlage sollen diese ebenfalls 
Berücksichtigung finden, insbesondere bei der Koordination der durch den 
Roboter und der durch den Menschen oder auch gemeinsam ausgeführten 
Schritte, bei der sich verschiedene Fragen zur Synchronisation ergeben. Die 
gesamte Steuerung soll dabei aktuellen Industriestandards entsprechen und 
ausreichend generisch sein, um nicht von bestimmten Roboterherstellern 


oder -typen abzuhängen. 


Monitoring der Montageprozesse 

Wie die meisten industriellen Prozesse sollen auch kollaborative Montage- 
prozesse, während sie stattfinden, überwacht werden, damit bei Unregelmä- 
Bigkeiten eingegriffen und eine erneute Stabilität des Ablaufs hergestellt 
werden kann. Auch für die direkte Beobachtung von veränderten Rahmenbe- 
dingungen oder Abläufen ist es erforderlich, jederzeit einen aktuellen und 
umfassenden Überblick über den Zustand der Anlage zu haben. Von etablier- 
ten nicht-kollaborativen Prozessen können dabei viele bekannte Indikatoren 
(zum Beispiel Durchlaufzeiten) übernommen werden. Jedoch ergeben sich 
durch die besonderen Eigenschaften der von Mensch und Cobot gemeinsam 
durchgeführten Arbeitsschritte zusätzliche besondere Merkmale (Key Per- 
formance Indicator), die im Rahmen des Monitorings beobachtet werden 


sollen. 


Dabei soll auch hier durch die konsequente Nutzung von OPC UA als Stan- 
dard die optimale Verfügbarkeit für weitere Informationskonsumenten herge- 
stellt und eine innerhalb der Gesamtmethodik einheitliche Darstellung und 
Homogenisierung der Datenmodelle und -flüsse angestrebt werden. Dazu 
müssen an der realen oder virtuellen Montagezelle alle verfügbaren Daten 


über ihren Zustand zur Verfügung gestellt werden. Diese sollen dann von 
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einem für das Monitoring geeigneten Werkzeug in Beinahe-Echtzeit abgeru- 
fen, ausgewertet und dargestellt werden. Dieses erlaubt dem Benutzer, den 
Zustand der kollaborativen Zelle zu bewerten und Abweichungen von der 


Erwartung zu erkennen. 


Persistierung von Prozessdaten 

Eine sich direkt aus der Forschungsfrage ergebende Anforderung betrifft 
die adäquate Persistierung aller bei der kollaborativen Montage entstehen- 
den Prozessdaten, da diese im Sinne eines Kreislaufs permanenter Pro- 
dukt(ions)verbesserung für zukünftige Engineering-Schritte zur Verfügung 
stehen sollen (siehe auch Abbildung 4.1). Die bei der Ausführung entstehen- 
den Daten sollen jedoch nicht nur gespeichert, sondern auch in einer für die 
weitere Nutzung, insbesondere die Analyse zum Zwecke des Re-Engineering, 
geeigneten Form wieder zur Verfügung gestellt werden. Im Rahmen der 
konsequenten Nutzung von OPC UA als Grundlage der Informationsflüsse ist 
es auch an dieser Stelle wünschenswert, die historischen Daten gemäß Teil 11 
der Spezifikation („Historical Access“) zur Verfügung zu stellen. Abgesehen 
von der Auswahl und Semantik der zu speichernden Daten gibt es in die- 
sem Anforderungsbereich keine für die kollaborative Montage spezifischen 
Fragestellungen. Dennoch ist er integraler Bestandteil eines kollaborativen 
Informationsmanagements, das unter anderem auch die flexible Anpassung 
von Montageplätzen und die schnelle Wandelbarkeit im Hinblick auf andere 


Produktvarianten zum Ziel hat. 


Analyse von Prozessdaten 

Der in Abbildung 4.1 auf der nächsten Seite dargestellte Kreislauf wird ver- 
vollständigt durch die Analyse der bei früheren Montageprozessen erfassten 
Daten. Dabei soll die Analyse insbesondere bestehende Optimierungspoten- 


ziale aufzeigen, mit deren Ausschöpfung der kollaborative Prozess weiter 


75 


4 Methodik für das Informationsmanagement 


Re-Engineering Digitaler Zwilling 
(Produkt und Anlage) 
und Arbeitspläne 


Analyse der Ausführung 
Prozessdaten (virtuell oder real) 


Persistierung der 
Prozessdaten 


Abbildung 4.1: Prozessdaten im Kreislauf der kontinuierlichen Produktionsoptimierung. 


verbessert werden könnte, einerseits unter ökonomischen Aspekten, ande- 
rerseits aber auch im Hinblick auf weitere Ziele wie Ergonomie, Sicherheit 
oder Produktqualität. Die besondere Herausforderung besteht hier in der 
Identifikation geeigneter Indikatoren zur Bewertung verschiedener Aspekte 
der kollaborativen Montage. Diese müssen dann entsprechend statistisch und 
grafisch aufbereitet und über geeignete Schnittstellen zur Verfügung gestellt 


werden. 


4.2 Manufacturing Integration Bus 


In diesem Kapitel wird ein Verfahren vorgestellt, das als zentrale Instanz den 
Informationsfluss bei der kollaborativen Montage steuern kann und damit das 
Rückgrat der Datenströme und zugleich die Basis der Integration verschiede- 
ner Systeme bildet. Aufgrund dieser wesentlichen Rolle bei der Integration 
der Datenflüsse bei der Montage trägt es den Namen „Manufacturing Inte- 
gration Bus“ (Schneider 2019). 


Einen vereinfachten Überblick über die verschiedenen Aufgaben des Manu- 


facturing Integration Bus im Kontext der gesamten Methodik gibt Abbildung 
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4.2. Grundsätzlich sind zwei Phasen zu unterscheiden: die erste umfasst 
alle Aktivitäten bis zum Zeitpunkt der Inbetriebnahme der realen Zelle und 
dem Beginn der tatsächlichen Montage, die zweite beginnt in diesem Mo- 
ment. Die zur Montage eines Produkts vorgesehene Zelle existiert, ebenso 
wie das Produkt selbst, in der ersten Phase nur als Digitaler Zwilling, der 
im AutomationML-Format beschrieben und iterativen konstruktiven Anpas- 
sungen unterworfen ist. Diese können durch physikalische Simulation der 
Montage unterstützt werden. Bereits in dieser Phase könnte der Manufactu- 
ring Integration Bus alle Integrationsaufgaben übernehmen, obwohl in der 
praktischen Anwendung dies in den meisten Fällen erst in der zweiten Phase, 
der eigentlichen Montage, erforderlich sein dürfte. Bis zu diesem Zeitpunkt 
werden dennoch bereits alle Planungs- und Konstruktionsdaten der Zelle 


vom Manufacturing Integration Bus erfasst. 


Spätestens sobald die reale Anlage in Betrieb genommen wurde, übernimmt 
der Manufacturing Integration Bus auch die Aufgabe der Steuerung der 
kollaborativen Zelle auf Basis der durch den Konfigurator oder das ERP- 
System bereitgestellten Auftragsdaten. Zur Beschreibung der Arbeitspläne 
wird ein eigens entwickeltes Datenformat und zur Ansteuerung der Zelle eine 
für die kollaborative Montage entwickelte Steuerungslogik verwendet, die in 
Abschnitt 4.5 auf Seite 93 beschrieben ist. Die Kommunikation mit der Zelle 
erfolgt dabei ausschließlich über OPC UA. 


Der aktuelle Zustand der Zelle wird repräsentiert durch einen OPC-UA- 
Server mit entsprechend modellierter und auf der Beschreibung der Zelle in 
AutomationML basierenden Knotenstruktur, der diese Daten dem Integration 
Bus zur Verfügung stellt. Dieser agiert als OPC-UA-Client und verwendet 
die Zustandsdaten aus der Zelle in mehrfacher Weise. Einerseits dienen sie 
als Grundlage der Zellensteuerung, andererseits werden sie aber auch für 
Zwecke des Monitorings benötigt und zusätzlich für die spätere Verwendung 
bei der Analyse persistiert. Damit ergibt sich die letzte wesentliche Aufgabe 


des Manufacturing Integration Bus: er stellt die gespeicherten Prozessdaten 
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Abbildung 4.2: Ubersicht zur Rolle des Manufacturing Integration Bus im Kontext der gesam- 
ten Methodik. Vergrößerung in Abbildung A.3 auf Seite 156. 


für Analysezwecke zur Verfügung, zum Beispiel per OPC UA Historical 
Access (Teil 11 der Spezifikation, OPC Foundation (2015)). 


Die Realisierung der oben beschriebenen Funktionalitäten erfordert neben 
einer einheitlichen Vernetzung (auf IP-Basis) eine Instanz, die einerseits 
verschiedene Protokolle und Formate verarbeiten kann und andererseits die 
Konfiguration komplexer Prozesse erlaubt. Der Manufacturing Integration 
Bus kann daher mit Hilfe einer geeigneten Integrationsplattform, die ge- 
nau diese Möglichkeiten bietet, implementiert werden. Ähnliche Konzepte 
kommen bereits seit Jahren in anderen Bereichen wie der Integration betriebs- 
wirtschaftlicher Daten zum Einsatz und werden auch als „Enterprise Service 
Bus“ bezeichnet. Es sind einige Produkte dieser Klasse am Markt vertreten, 


bei der Implementierung der hier beschriebenen Methodik kommt die See- 
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burger Business Integration Suite! zum Einsatz. Sie besteht aus einer Reihe 
von Werkzeugen, die gemeinsam die Modellierung und Automatisierung von 
Datenaustauschprozessen auch im Industrial Internet of Things erlauben. Im 
Mittelpunkt steht der BIS Integration Server, der mit zahlreichen Protokoll- 
Adaptern auf Basis etablierter Standards wie Business Process Execution 
Language (BPEL) den Austausch von Daten auf den verschiedensten Wegen 
ermöglicht. Gleichzeitig kann mit dem Business Integration Converter mit 
Hilfe von Mappings auch eine Konversion in verschiedenste Datenformate 
durchgeführt werden. Ein Beispiel für einen einfachen Prozess ist die Annah- 
me einer XML-Datei über SFTP, eine Konvertierung des Formats und die 
Weitergabe der veränderten Datei über eine HTTP-basierte API. 


Die an den Manufacturing Integration Bus angebundenen Systeme mit ihren 
Schnittstellen zeigt Abbildung 4.3 auf der nächsten Seite, die den Schwer- 
punkt im Vergleich zur Abbildung 4.2 nicht auf die Bedeutung der einzelnen 
Verknüpfungen, sondern auf deren technische Realisierung mit verschiedenen 
Schnittstellen und Protokollen setzt. Vom ERP-System erhält der Manufactu- 
ring Integration Bus den eigentlichen Auftrag zur Montage einer bestimmten 
Variante eines Produkts über eine je nach verwendetem ERP-System anpass- 
bare API. Die zur Ausführung erforderlichen kollaborativen Arbeitspläne 
hält das MES bereit und stellt diese über einen SFTP-Client (oder alternativ 
eine individuelle APD) bereit. Der Arbeitsplan kann nun in der Simulation, 
zu der der Datenaustausch in dem in Abschnitt 4.5 näher beschriebenen 
Format CollabML per SFTP erfolgt, virtuell geprüft werden. Dabei werden 
alle Arbeitsschritte physikalisch simuliert, so dass Kollisionen oder andere 
bisher unbekannte Schwierigkeiten erkannt werden können. Eventuell erfor- 
derliche Anpassungen werden dem Manufacturing Integration Bus wiederum 
im CollabML-Format per SFTP als geprüfter Arbeitsplan zurückgegeben 
(Schneider 2019). 


l https://www. seeburger .de 
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Abbildung 4.3: Der Manufacturing Integration Bus mit den angebundenen Systemen und 


Schnittstellen. 


Dieser Arbeitsplan kann nun in der realen Montagezelle zur Ausführung 
gebracht werden, wobei die eigentliche Steuerung ganz oder teilweise vom 
Manufacturing Integration Bus übernommen werden kann. Möglich ist auch 
eine zweistufige Ausführung der einzelnen Schritte des Arbeitsplanes, bei der 
die Steuerung die Details der Kollaboration an die Zelle oder den Werker dele- 
giert (siehe auch Abschnitt 4.5 auf Seite 93). Aus der Sicht des Manufacturing 
Integration Bus erfolgt die gesamte Kommunikation mit der Montagezelle 
(untere Hälfte der Abbildung 4.3) per OPC UA. Der im Manufacturing Inte- 
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gration Bus integrierte OPC-UA-Client ruft auf dem OPC-UA-Server, der 
an SPS und Robotersteuerung unmittelbar angeschlossen ist, entsprechen- 
de OPC-UA-Methoden auf, die Aktionen in der Zelle starten. Ein als HMI 
ebenfalls per OPC UA verbundenes Werker-Terminal bildet einerseits die 
Schnittstelle zum Werker und gestattet andererseits Eingriffe in den kollabo- 
rativen Arbeitsablauf. Über den in den Manufacturing Integration Bus inte- 
grierten OPC-UA-Server kann der die Kommunikation des Werker-Terminals 
steuernde OPC-UA-Client auch Arbeitspläne abrufen, insbesondere für den 
Fall, dass die Steuerung nicht vom Manufacturing Integration Bus selbst 


übernommen wird. 


Über diese OPC-UA-Verbindungen empfängt der OPC-UA-Client des Manu- 
facturing Integration Bus aber auch die Zustandsdaten der Anlage, die der 
OPC-UA-Server zur Verfügung stellt. Diese sind im Allgemeinen nur die 
aktuellen Zustandsdaten (Modus „Data Access“), so dass eine weitere Funk- 
tion des Manufacturing Integration Bus in der Persistierung der Prozessdaten 
für spätere Analysezwecke besteht. Der integrierte OPC-UA-Server stellt 
die Daten im Modus „Historical Access“ über längere Zeiträume vollständig 


oder aggregiert für die Analyse zur Verfügung. 


Damit ist der Manufacturing Integration Bus die zentrale Instanz des an kol- 
laborative Montage mit aktuellen Standards angepassten Product Lifecycle 
Managements und enthält mehrere Komponenten, die die einzelnen Anfor- 
derungen abdecken. Diese einzelnen Komponenten, ihre Aufgaben und ihre 
Rolle im gesamten System wird in den folgenden Kapiteln näher beschrieben. 
Einen Überblick dazu gibt Abbildung 4.4. 


Im Mittelpunkt steht der Manufacturing Integration Bus, der die digitalen 
Zwillinge von Produkt und Anlage und die bei der Montage gewonnenen 
Prozessdaten speichert und sie den darum angeordneten Prozessen im pas- 


senden Format zur Verfügung stellt. Auf dieser Basis kann die Simulation 
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Abbildung 4.4: Überblick über die einzelnen Komponenten der Gesamtmethodik mit dem 
Manufacturing Integration Bus im Zentrum. 


beliebig oft wiederholt werden, aber auch die Steuerung der Montage ge- 
startet oder eine Analyse historischer Daten durchgeführt werden. Während 
der Montage ist das Monitoring aktiv, dessen Ergebnisse wiederum Einfluss 
auf die laufende Montage haben können. Die bei der Montage entstehenden 
Prozessdaten werden vom Manufacturing Integration Bus gespeichert und 


stehen dort für spätere Analysen zur Verfügung. 


4.3 Produkt- und Anlagen-Lebenszyklus 


Sowohl das montierte Produkt selbst als auch die dazu verwendeten Produk- 
tionsmittel unterliegen einem Lebenszyklus. Während das Management des 


Produktlebenszyklus weit verbreitet ist und diverse Vorteile bekannt sind 
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(Ameri und Dutta 2005; J. Stark 2015), ist dies bei der analogen Sichtweise 
auf die Anlage selbst noch nicht in diesem Maße der Fall. Doch die Montage 
zahlreicher Varianten eines Produkts in relativ geringen Stückzahlen (siehe 
auch Unterabschnitt 2.3.1 auf Seite 28) und die damit einhergehende mög- 
lichst flexible Wandelbarkeit der Anlage rücken zunehmend die Sichtweise 
in den Vordergrund, auch die Anlage selbst als Produkt mit den bekannten 


Phasen innerhalb des Lebenszyklus zu sehen. 


Die Lebenszyklen von Produkt und Anlage sind in Abbildung 4.5 schema- 
tisch dargestellt. Das Produkt entsteht vom Konzept über die Entwicklung 
und Prototypen, wird hergestellt, genutzt und letztlich recycelt. Die dazu 
notwendige Anlage wird entwickelt, simuliert, aufgebaut, betrieben, zurück- 
gebaut und ebenfalls recycelt. Auch wenn die Beschaffenheit des Produkts 
bereits auf die Entwicklung der Anlage einwirkt, ist der entscheidende Be- 
rührungspunkt die Herstellung des Produkts durch den Betrieb dieser Anlage. 
Im Fall kollaborativer Montage variantenreicher Produkte ist hier ein weiterer 
Zyklus zu finden, der neben der Produktion die wiederholte Rekonfiguration 
der Anlage beinhaltet, die durch Simulation geprüft werden kann (siehe auch 
Abbildung 4.1 auf Seite 76). Die Simulation spielt also sowohl während der 
Anlagenplanung als auch während des Betriebs eine besondere Rolle, wobei 
in der Praxis aus wirtschaftlichen Gründen der regelmäßige Einsatz auch 
entfallen kann (siehe auch Abbildung 4.3). Voraussetzung dieser Vorgehens- 
weise ist die Modellierung von Produkt und Anlage einschließlich Kinematik 


als „Digitaler Zwilling“. 


Dabei kommt das in Unterabschnitt 2.4.1 auf Seite 32 erwähnte AutomationML- 
Format zum Einsatz, das als Containerformat dient und unter anderem die 
Geometrie und Kinematik von Produkt und Anlage als CAEX-Format enthält 
und damit insbesondere für die Ausführung der Simulation die Basis bildet. 
Der Arbeitsplan wird im CollabML-Format gespeichert, das wiederum wei- 
tere XML-Dateien referenziert, die die Arbeitsanweisungen für die einzelnen 


Ressourcen enthalten. Je nach betrieblichem Umfeld kann hier auch ein PDM 
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Abbildung 4.5: Lebenszyklen von Produkt und Anlage und ihr Berührungspunkt bei der 
Montage von Produktvarianten durch Rekonfiguration und Simulation. 


und/oder MES zum Einsatz kommen, was an dieser Stelle jedoch nicht weiter 
vertieft werden soll, da es nicht im Rahmen der Zielsetzung dieser Arbeit 
liegt. Die Anpassung dieses Konzepts an reale Fälle aus der industriellen 


Praxis wird in den beiden weiteren Hauptkapiteln beschrieben. 


Den gesamten Ablauf einer kollaborativen Montage von der Bestellung bis 
zum fertigen Produkt in den Bereichen Planung und Montage zeigt über- 
blicksartig Abbildung 4.6 in BPMN-Notation. Die Nachricht, die den Prozess 
startet, kann eine Bestellung aus einem beliebigen System sein, das die Defini- 
tion einer Produktvariante erlaubt, also zum Beispiel ein Produktkonfigurator, 
der direkt dem Kunden zur Verfügung steht, ein interner Konfigurator oder 
auch eine ERP-Instanz. Für den Fall, dass exakt die in Auftrag gegebene 
Variante bereits schon einmal montiert wurde und die Umstände sich seitdem 
nicht signifikant geändert haben, kann unmittelbar mit der Montage durch 
Ausführung des bereits vorhandenen und erprobten Arbeitsplans begonnen 


werden. 


Handelt es sich um eine bisher noch nicht geplante Variante, werden im 


nächsten Schritt die erforderlichen Grundlagen wie die Stückliste und der 
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Abbildung 4.6: Workflow bei der kollaborativen Planung und Montage eines variantenreichen 
Produkts. 


Arbeitsplan erstellt, der dann in der Simulation geprüft wird. Sollten sich da- 
bei Probleme zeigen, zum Beispiel Kollisionen zwischen Anlagenteilen oder 
sicherheitsrelevante Probleme, wird die Planung überarbeitet. Diese beiden 
Schritte werden iterativ so lange wiederholt, bis die Simulation erfolgreich 


war und mit der Montage begonnen werden kann. 


Die zentrale Rolle beim Management dieser Abläufe nimmt im Rahmen 
der vorliegend vorgestellten Methodik der in Abschnitt 4.2 beschriebene 
Manufacturing Integration Bus ein. Für den Fall, dass kein MES oder PDM 
angebunden ist, verwaltet und speichert er die Produktkonfigurationen, Ar- 
beitspläne und Stücklisten, ansonsten hat er eine Schnittstelle zu diesen 
Systemen und stellt der Simulation und der Ausführung diese Datensätze zur 
Verfügung (siehe auch Abbildung 4.3). 
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Dieser Ablauf ist auch Teil der „KoKoMo-Methode“, benannt nach dem 
BMBF geförderten Forschungsprojekt „KoKoMo - Kompetenz Kollaborative 
Montage“, die im Überblick in Abbildung 4.7 dargestellt ist. Hier sind von 
oben nach unten die Schritte auf dem Weg von der kundenindividuellen 
Bestellung bis zum fertigen Produkt und ihre Verknüpfungen wiedergegeben. 
Soll eine bereits bekannte Konfiguration montiert werden, kann sofort die 
Produktionsplanung begonnen werden, ansonsten folgt zunächst die Gene- 
rierung grundlegender Daten wie der Produkt-Identifikationsnummer, der 
Stückliste und des Arbeitsplans. Auf deren Basis kann die Reihenfolge der 
Aufträge geplant werden und die Zuteilung zu vorhandenen Ressourcen 
erfolgen. Letzteres erfolgt im Idealfall fähigkeitsbasiert (siehe auch Unterab- 
schnitt 3.1.3). 


Ist der jeweiligen Ressource das Produkt schon bekannt, kann unmittelbar 
mit der kollaborativen Montage begonnen werden. Ansonsten wird der ge- 
samte Montageablauf in der physikalischen Simulation geplant und geprüft, 
insbesondere zum einen unter dem Aspekt der Sicherheit, denn es gilt Kol- 
lisionen und andere Ereignisse, die im schlimmsten Fall zu Verletzungen 
führen, zu vermeiden. Zum anderen findet hier die Roboterprogrammierung 
und Generierung kollisionsfreier Roboterbahnen und die Abschätzung der 
Durchlaufzeiten statt. Die nicht-deterministischen Aktionen des Menschen 
werden durch VR-Simulation berücksichtigt. Auf diese Weise können poten- 
zielle Kollisionen und andere Gefahren erkannt werden. Eine wesentliche 
Grundlage der Simulation ist die Verwendung eines umfangreichen Digitalen 
Zwillings von Produkt und Anlage (siehe auch Abschnitt 4.4). 


Während der kollaborativen Montage wird diese permanent überwacht, indem 
alle verfügbaren Daten einem Monitoring zugeführt werden. Verläuft sie 
ohne unerwartete Ereignisse und Änderung der Umstände, steht am Ende das 
fertige Produkt. Zeigen sich jedoch bei der Ausführung der realen Montage 


unerwartete Schwierigkeiten, kann jederzeit zur Simulation zurückgekehrt 
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Abbildung 4.7: Die KoKoMo-Methode: Workflow von der Bestellung zum finalen Produkt nach 
Herfs, Storms, Roggendorf, Petrovic, Schubert, Schneider, Erkayhan, Rückert, 
Tracht und Heinen 2019, S. 57. Vergrößerung in Abbildung A.2 auf Seite 155. 


werden und hier eine Änderung der Feinplanung erfolgen (Rückert, Tracht, 
Herfs, Roggendorf, Schubert und Schneider 2019). 


Die verschiedenen Informationsarten im rechten Teil der Abbildung ent- 
sprechen den links dargestellten Schritten und und bauen von oben nach 
unten teilweise aufeinander auf. Der Datenfluss in der umgekehrten Rich- 
tung, also von unten nach oben, dient der Konsolidierung und Optimierung 


der Prozesse. 
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4.4 Digitaler Zwilling 


Im Kontext der hier vorgestellten Methodik kommt die virtuelle digitale 
Repräsentation mehrerer realer Objekte zum Einsatz. Diese Modelle werden 
auch als „Digitaler Zwilling“ bezeichnet, ein Begriff, für den es (noch) keine 
einheitliche anerkannte Definition gibt. Die bisher am weitesten verbreitete 


und sehr häufig zitierte Definition von Glaessgen und Stargel (2012) lautet: 


„Der Digitale Zwilling ist eine integrierte multiphysikalische, 
multiskalige, probabilistische Simulation eines komplexen Pro- 
dukts und verwendet die besten verfügbaren physikalischen Mo- 
delle, Sensor-Updates usw., um das "Leben" des entsprechenden 


Zwillings wiederzugeben.“ 


Obwohl diese Definition von Glaessgen und Stargel (2012) vor dem Hinter- 
grund der Anwendung auf Luft- und Raumfahrzeuge gegeben wurde, hat 
sie doch eine hohe Allgemeingültigkeit. Zahlreiche weitere Definitionen 
existieren, jeweils für einen begrenzten Anwendungsbereich (Tao u.a. 2018; 
R. Stark, Kind und Neumeyer 2017). 


Neben vielen anderen Anwendungsgebieten kann das Konzept des Digitalen 
Zwillings auch in der Produktion und insbesondere der Montage sinnvoll 
eingesetzt werden, und zwar in mehreren Stadien des Lebenszyklus von 
Produkt und Anlage von der Konzeptphase über das Design bis zur Feinpla- 
nung und in besonderen Fällen sogar bis zur Wartung. Der obigen Definition 
folgend kann der Digitale Zwilling dabei grundsätzlich zahlreiche Merkma- 
le umfassen, wobei in den meisten Anwendungsfällen nur eine bedeutend 
weniger mächtige echte Teilmenge der theoretisch möglichen Entitäten zum 
Einsatz kommen wird. Im Rahmen der hier vorgestellten Methodik werden 


das Produkt und die Anlage zu seiner Montage virtuell repräsentiert. 
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Diese Abbilder von Produkt und Anlage entstehen während der Produktent- 
wicklung und stellen eine Beschreibung einer Klasse von Objekten dar. Der 
Digitale Zwilling des Produkts enthält unter anderem Konstruktionsdaten, 
Funktionsbeschreibungen und Montageinformationen und ist auch Teil des 
PLM-Systems (Herfs, Storms, Roggendorf, Petrovic, Schubert, Schneider, 
Erkayhan, Rückert, Tracht und Heinen 2019, S. 54). Im Laufe des Produktle- 
benszyklus wird der Digitale Zwilling in mehreren Schritten mit weiteren 
Informationen angereichert (siehe auch Abbildung 1.3 auf Seite 7). Bei einem 
Produkt ohne Varianten könnte der vollständige Arbeitsplan mit Informa- 
tionen zu Durchlaufzeiten oder der Nutzung von Betriebsmitteln bereits 
enthalten und Ergebnis der Produktentwicklung sein. Bei variantenreichen 
Produkten ist ein anderer Weg sinnvoll, der im Folgenden ausführlicher be- 
schrieben wird und direkt Bezug nimmt auf Teilforschungsfrage F2. Nur 
am Rande wird auf die Physikalische Simulation selbst eingegangen, die in 
dieser Methodik zwar genutzt wird, deren Details aber nicht Thema dieser 
Arbeit sind. 


Grundlage der weiteren Nutzung ist also die Beschreibung von Produkt und 
Anlage, die in AutomationML (siehe auch Unterabschnitt 2.4.1 auf Seite 32) 
erfolgen kann. Dazu stehen verschiedene Editoren zur Verfügung, z. B. der 
Asset Configuration Manager aus dem Skillpro-Projekt (Pfrommer, Stogl u.a. 
2014). Ein für die Simulation zentraler Bestandteil ist das Modell des verwen- 
deten Roboters, das im Allgemeinen vom Roboterhersteller zur Verfügung 
gestellt wird. Dieses muss kinematisiert werden und bildet zusammen mit den 
übrigen Bestandteilen der Anlage den Digitalen Zwilling der Anlage. Auch 
zu einer verallgemeinerten Beschreibung des Produkts, die alle Varianten 


umfasst, eignet sich AutomationML. 


Einen Überblick über die Art und Weise der Nutzung des Digitalen Zwil- 
lings in dieser Methodik gibt Abbildung 4.8, deren Zentrum wiederum eine 
bestimmte Sichtweise auf den Manufacturing Integration Bus mit einigen 


Verarbeitungsschritten des Digitalen Zwillings bildet. 
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Abbildung 4.8: Stufen der Nutzung des Digitalen Zwillings von der Konfiguration einer 
Variante bis zur Ausführung der kollaborativen Montage. 


Ausgangspunkt sind der für alle Varianten des Produkts gültige Digitale 
Zwilling des Produkts, die Beschreibung der Anlage und ihrer Fähigkeiten 
und die Konfiguration einer einzelnen speziellen Variante. Zur Ablage der 
Produktdaten wird häufig ein PDM-System verwendet, der einzelne Auftrag 


zur Montage einer bestimmten Variante des Produkts wird im Allgemeinen 
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in einem ERP-System verwaltet. Diese Informationen werden im Manufactu- 
ring Integration Bus zusammengeführt und mittels einer fähigkeitsbasierten 
Aufgabenzuteilung zu einer auf die konkrete einzelne Produktvariante be- 
zogenen Arbeitsplanung aggregiert. Diese wird in CollabML (siehe auch 
Anhang A.2) gespeichert, das im Anhang in seiner einfachsten Version be- 
schrieben und mit einem Beispiel versehen ist. Bereits an dieser Stelle ist 
die Entscheidung enthalten, ob eine bestimmte Aufgabe vom Roboter, vom 


Werker oder auch von beiden erledigt werden kann. 


Der folgende Schritt könnte entfallen, wenn die Simulation CollabML als 
Eingabeformat akzeptieren würde. Da dies in den für Tests verwendeten 
Implementierungen nicht der Fall war und auch allgemein nicht davon ausge- 
gangen werden kann, wird der Arbeitsplan im nächsten Schritt vom Manu- 
facturing Integration Bus in ein für die Simulation als Eingabe geeignetes 
Format transformiert (siehe auch Mitte der Abbildung 4.8). In dieser Form 
kann die kollaborative Montage auf Basis des konkreten Arbeitsplans für die 


spezielle Variante simuliert werden. 


Die sich anschließende Simulation (siehe auch Abbildung 4.9) verfolgt meh- 
rere Ziele: Einerseits soll die Arbeitsplanung weiter verfeinert werden, indem 
bisher fehlende Parameter ergänzt werden, zum Beispiel die präzise Bahnpla- 
nung des Roboters. Dies kann auch mittels Teaching erreicht werden, falls 
erforderlich. Andererseits dient die Simulation aber auch der Absicherung 
des Arbeitsplans im Sinne einer möglichen kollisionsfreien Ausführung. Eine 
in der Simulation entdeckte Kollision kann in diesem Stadium noch ohne 
weiteren physischen Schaden an der Anlage durch Anpassung des Arbeits- 
plans korrigiert werden (Rückert, Tracht, Herfs, Roggendorf, Schubert und 
Schneider 2019). 


Dabei geht es nicht nur um Kollisionen zwischen Anlagenteilen, sondern 
natürlich im kollaborativen Fall um auch um mögliche Gefahren für den Wer- 


ker. Das Verhalten des Werkers ist nicht determiniert und daher schwer zu 
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Abbildung 4.9: Screenshot von der Nutzung des Digitalen Zwillings zur Simulation der kollabo- 
rativen Montage am Beispiel der Experimentellen Modularen Montageanlage 
(EMMA) des Bremer Instituts für Strukturmechanik und Produktionsanlagen 
(BIMB). 


simulieren. Ein möglicher Ansatz ist die Verwendung von AR/VR-Methoden 
zur Abbildung des normalen Verhaltens eines menschlichen Werkers. Unge- 
wöhnliche und unerwartete Verhaltensweisen des Werkers können mit diesem 
Ansatz jedoch nicht berücksichtigt werden. Am Ende der Simulation (und 
nach eventuell iterativer Anpassung des Arbeitsplans) steht eine abgesicherte 
Feinplanung, die an den Manufacturing Integration Bus zurückgegeben und 
dort in das ursprüngliche CollabML-Format retransformiert wird. Der Da- 
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tenaustausch zwischen Manufacturing Integration Bus und Simulation kann 


dabei aus simplen SFTP-Verbindungen bestehen. 


Der resultierende finale Arbeitsplan wird im Manufacturing Integration Bus 
bereitgehalten und kann jederzeit zur Steuerung der kollaborativen Montage 
verwendet werden. Der Digitale Zwilling besteht weiterhin und wird auf 
Basis weiterer Erkenntnisse aus der tatsächlichen Montage kontinuierlich 
angepasst. Dieser umfangreichere Zyklus der iterativen Anpassung der digita- 
len Grundlagen der Montage wird in den folgenden Kapiteln beschrieben, die 
sich mit der Erfassung, dem Monitoring und der Analyse der bei der realen 


kollaborativen Montage entstehenden Daten beschäftigen. 


Die oben beschriebene Nutzung eines Digitalen Zwillings bei der Planung 
und Absicherung der kollaborativen Montage beantwortet die Teilforschungs- 
frage F2, indem sie zur Steigerung der Sicherheit und Effizienz der kollabo- 
rativen Montage beiträgt. Die komplexe Frage der Aufteilung der einzelnen 
Aufgaben zwischen Mensch und Roboter (Blankemeyer u. a. 2019) ist damit 
jedoch erst teilweise beantwortet, wie sich im folgenden Kapitel zeigen wird, 


das die Steuerung der kollaborativen Montage beschreibt. 


4.5 Steuerung der kollaborativen Zelle 


Eine weitere wichtige Komponente bei der kollaborativen Montage und 
der durch die Produktvariabilität geforderten einfachen und schnellen Re- 
konfigurierbarkeit der Anlage ist die adäquate Steuerung der Abläufe un- 
ter Einbeziehung aller Werker, Roboter und Werkzeuge (Ressourcen). Die 
hier vorgestellte Methode geht davon aus, dass bereits ein Arbeitsplan, der 
den Ablauf der Montage beschreibt, existiert. Dieser kann manuell in der 
Engineering-Phase festgelegt oder auch dynamisch erzeugt worden sein, zum 
Beispiel durch den Abgleich von benötigten und vorhandenen Fertigkeiten 
(„Skills“) (siehe auch Unterabschnitt 3.1.3). Auch die regelbasierte Ableitung 
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des Arbeitsplans auf Basis der mit einem Konfigurator erzeugten Produkt- 
variante ist ein möglicher Weg. Der Arbeitsplan enthält alle zur Montage 
der jeweiligen Variante des Produkts erforderlichen Schritte und eine Infor- 
mation, durch welche Ressource sie ausgeführt werden können bzw. sollen. 
Es ist möglich, dass nur eine Ressource dafür in Frage kommt, es können 
auch mehrere sein. In diesem Fall ist die bevorzugte (Default) deklariert. Da 
bisher kein für diese Zwecke geeignetes Datenmodell und Beschreibungs- 
format existierte, wurde im Rahmen dieser Arbeit „CollabML“ entwickelt, 
ein einfaches XML-Format zur Beschreibung kollaborativer Montageabläufe. 
Aufgrund der XML-basierten Form ist es einerseits bei Bedarf in Automati- 
onML oder ähnliche Containerformate integrierbar, andererseits aber auch 
selbst für Erweiterungen offen, zum Beispiel zur Berücksichtigung spezifi- 
scher Parameter für einzelne Ressourcen. Insbesondere die für die jeweilige 
Ressource zutreffende Beschreibung der Aufgabe ist hier ausdrücklich nicht 
festgelegt, um die Offenheit und Erweiterbarkeit für zusätzliche Ressourcen 
zu gewährleisten. Gleichzeitig ist gewährleistet, dass der Arbeitsplan maschi- 
nenlesbar ist. Verschiedene Methoden zur Erzeugung des Arbeitsplans und 
insbesondere der Zuordnung der Ressourcen bei der kollaborativen Montage 


stellt Blankemeyer u. a. (2019) gegenüber. 


Eine CollabML-Datei enthält genau einen Montageauftrag, der zur Fertigstel- 
lung eines einzelnen Produkts führt. Der gesamte Auftrag besteht aus einer 
oder mehreren Aufgaben, die wiederum von einer oder mehreren Ressourcen 
ausgeführt werden können. Dieses grundlegende Datenmodell ist zusammen- 
fassend in Abbildung 4.10 dargestellt, die jedoch insofern nicht vollständig 
ist, dass die Teile des Modells zur konkreten Beschreibung der Aufgabe nicht 
enthalten sind, sondern nur die für die im Folgenden beschriebene Steuerung 
relevanten. Dazu gehört neben eindeutigen IDs aller Entititäten insbesondere 
zu jeder Aufgabe die Liste aller Aufgaben, die erledigt sein müssen, bevor mit 
der Aufgabe selbst begonnen werden kann. Die eigentliche Beschreibung der 


zur Durchführung der Aufgabe erforderlichen Schritte ist abhängig von der 
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Ressource, so dass deren Feld „taskDescription“ hier als Platzhalter für ein 
weiteres geeignetes Format steht. Dieses kann im Fall der Ressource Cobot 
ein Roboterprogramm sein, im Falle der Ressource Werker eine Beschreibung 
in Text und Bild, z. B. PDF, HTML, etc. 


AssemblyOrder 


+id 
+productld 


"waitForTasks" enthält eine 
Liste von Task IDs. Diese 
Tasks sind Vorgänger, müssen 
also vor Ausführung des Tasks 
abgeschlossen worden sein. 


+waitForTasks 
+name 
+defaultResource 


"taskDescription" enthält die zur 
Ausführung erforderlichen 
Informationen in der für die 
jeweilige Ressource geeigneten 
Form (z.B. Roboterprogramm 
oder Video für Werker). 


+id 
+name 
+taskDescription 


Abbildung 4.10: Vereinfachtes grundlegendes Datenmodell fiir CollabML zur Beschreibung 
kollaborativer Arbeitspläne. 


Eine Definition von CollabML im XSD-Format und ein Beispiel dazu be- 
finden sich im Anhang A.2 auf Seite 161. Die entsprechende schrittweise 
-teilweise parallele- Ausführung dieses Beispiels zeigt Abbildung 4.11. 
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Worker Cobot 


Task #2 | Synchronität | Task #1 


Task #3 
wartet auf 
Task #4 
y 
Ende 


Abbildung 4.11: Beispielhafter möglicher Ablauf einer Montage nach dem in CollabML 
formulierten Arbeitsplan (s. a. Anhang A.2). 


Ein möglicher Ablauf der Montage nach diesem Beispiel-Arbeitsplan könnte 
wie folgt ablaufen: Die erste Aufgabe („Pick & Place part 378“) könnte nach 
dem Arbeitsplan sowohl vom Werker als auch vom Cobot erledigt werden. 
Als Standardressource ist der Cobot festgelegt, der also die Ausführung be- 
ginnt. Der Werker stellt inzwischen fest, dass er schon die nächste Aufgabe 
übernehmen könnte, für die standardmäßig zwar auch der Cobot vorgesehen 
ist, aber die auch der Werker übernehmen kann. Diese Entscheidung steuert 
er über das am Control Wrapper (s.u.) angeschlossene HMI. Mit Hilfe des 
„<waitForTasks>“-Tags ist in diesem Beispiel festgelegt, dass mit der Ausfüh- 
rung von Aufgabe 3 erst begonnen werden kann, wenn die Aufgaben | und 
2 abgeschlossen sind. Und Aufgabe 3 kann auch nur vom Werker erledigt 
werden. Ebenso kann auch Aufgabe 4 erst nach Abschluss von Aufgabe 3 be- 
gonnen werden, deren Ausführung der Werker in diesem Beispiel dem Cobot 


überlässt. Damit ist die Ausführung dieses Beispiel-Arbeitsplans abgeschlos- 
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sen. Die einzelnen referenzierten XML-Dateien mit den Instruktionen für die 
einzelnen Aufgaben sind hier nicht wiedergegeben. Sie sind individuell auf 


die jeweilige Ressource anzupassen. 


Bei der Gestaltung und Ausführung des kollaborativen Arbeitsplans wird 


von mehreren Voraussetzungen ausgegangen: 


e Jede Aufgabe muss von mindestens einem der vorhandenen Assets 


ausführbar sein, da ansonsten eine Blockierung eintreten würde. 


e Es gibt Aufgaben, die nur vom Werker oder nur vom Roboter (allge- 


meiner nur von einer einzigen Ressource) erledigt werden können. 


e Es kann aber auch Aufgaben geben, die sowohl vom Roboter als auch 
vom Werker (allgemeiner von mehreren Ressourcen) ausgeführt wer- 
den können. In diesem Fall ist festgelegt, wer die Aufgabe im Normal- 
fall („Default“) erledigen soll. 


e Der Werker kann bei Aufgaben, für die mehrere mögliche Ausführende 


deklariert sind, entscheiden, wer die Aufgabe tatsächlich übernimmt. 


Gerade der letzte Punkt ist in der Literatur nicht unumstritten, da letztlich 
die Frage dahintersteht, ob der Mensch bei der Montage die führende Rolle 
übernimmt oder nicht. Hier sind nicht nur technische, sondern auch weitere 
Aspekte wie zum Beispiel die organisatorische Effizienz oder die Mitarbeiter- 
Compliance zu beachten bis hin zu philosophischen und ethischen Überle- 


gungen. 


Zentrale Instanz der Steuerung der kollaborativen Zelle ist die in den Ma- 
nufacturing Integration Bus integrierte „Control Engine“. Ihre Aufgabe ist 
die schrittweise Abarbeitung des Arbeitsplans und der Transfer der Details 
einer Aufgabe über den mit ihr verbundenen OPC-UA-Client an den OPC- 
UA-Server der Montagezelle (siehe auch Abbildung 4.12). Dazu wird eine 
OPC-UA-Methode auf dem Server aufgerufen, die das die Details enthaltende 
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XML-Snippet als Eingabeparameter akzeptiert. Dieser Ansatz adressiert die 


mit Teilforschungsfrage F3 in Zusammenhang stehenden Anforderungen. 


Liste ausführ- 


Wenn Ressource frei barer Aufgaben 


n Manufacturing Integration Bus 


I 
i 
[i 
| 
[i 
dann starte Aufgabe. L 
I 


1 
i 
i 
! und Bedingungen erfüllt, 
L 


Control Engine 


OPC UA Client 


i] 
1 
OPC UA Nodes 
1 I 

Methodenaufruf rs Access l Ressource Se i 
Resscurcen) ı Aufgabe in Ausführung i 

1 | 


XML Parser für Aufgaben, OPC UA Server 


Umsetzung in Roboter- 


oder SPS-Programm oder ı____ EECHER 
Anzeige am Terminal "Control Wrapper Je Ressource 
WS a oN ate le SERIE: | ı eine Queue aus- |! 
ee 1 führbarer Aufgaben 
SPSund ` ENDEN EE i 

Robotersteuerung Werker kann Bull ablehnen 


oder an Stelle des Röboters übernehmen. 
Es A ` 
HMI 


Werker-Terminal 


Roboter Weitere Assets 


Abbildung 4.12: Überblicksdarstellung zur Steuerung kollaborativer Arbeitsschritte durch die 
Control Engine des Manufacturing Integration Bus. 


Gegenstück der Control Engine im Manufacturing Integration Bus ist der 
„Control Wrapper“, der die Details einer Aufgabe vom angegliederten OPC- 
UA-Server entgegennimmt. Die in der Zelle zur Verfügung stehenden Assets 
sind im angebundenen OPC-UA-Server als Knoten modelliert und ihr jewei- 
liger Status, insbesondere die Unterscheidung zwischen „beschäftigt“ und 
„nicht beschäftigt“, steht damit dem OPC-UA-Client der Control Engine zur 


Verfügung. Die einzelnen Aufgaben sind durch eine eindeutige Nummerie- 
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rung (IDs) voneinander zu unterscheiden und der Control Wrapper stellt über 
einen weiteren Knoten die Liste aller bereits erledigten Aufgaben bereit. Es 
gibt bei der Montage natürlich Aufgaben, die erst erledigt werden können, 
nachdem andere erledigt wurden und die durch entsprechende Definition 
des „waitFor“-Feldes (Liste) in CollabML konfiguriert worden sind. Ist eine 
Ressource frei und sind alle Voraussetzungen (Vorgänger) erfüllt, sendet die 
Control Engine das die Aufgabe beschreibende Snippet (,,taskDescription“) 
an den Control Wrapper. 


Dieser führt für jede Ressource eine Queue der zu erledigenden Aufgaben, 
die auch dem Werker über ein Display angezeigt werden. Für Aufgaben, 
die von mehreren Ressourcen erledigt werden könnten, kann der Werker 
selbständig Verschiebungen vornehmen und Aufgaben anderen Ressourcen 
zuordnen. Die Logik des Control Wrappers verhindert dabei Veränderungen, 
die zu Blockierungen führen könnten, indem regelbasiert die Integrität des 
Arbeitsplans überprüft wird. Damit wird beispielsweise verhindert, dass der 
Werker Aufgaben übernimmt, die nur der Roboter übernehmen soll. Diese 
manuellen Eingriffe durch den Werker sind jedoch optional und ohne sie 
steuert die Control Engine die Abläufe im klassischen Sinne analog einer 
voll automatisierten Montage. Eine weitere zentrale Aufgabe des Control 
Wrappers besteht in der Umsetzung der Aufgabe in die jeweilige Sprache der 
angesteuerten Ressource. Die Schnittstelle zwischen etabliertem Standard 
(OPC UA) und erforderlicher individueller Anpassung an die vorhandenen 
Ressourcen erfolgt durch den Control Wrapper, der für die Adaption und 
Verteilung an die verschiedenen Ressourcen sorgt. Dies kann im Fall von 
Informationen für den Werker die Anzeige eines Textdokuments, von Bildern 
oder Videos oder auch eine Sprachausgabe am HMI sein. Bei einem Roboter 
als Ressource wird es sich in den meisten Fällen um ein in der Roboter- 
steuerung ausführbares Programm handeln, das entweder auf den jeweiligen 
Robotertyp zugeschnitten oder in einer allgemeineren Form (Bahnparameter 


etc.) dargestellt ist und interpretiert wird. 
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Die auf diese Art und Weise durch CollabML und die oben beschriebe- 
ne Steuerungslogik mit OPC UA als grundlegendem Standard realisierte 
Ansteuerung einer kollaborativen Zelle ermöglicht einerseits eine direkte 
Ansteuerung einzelner Ressourcen und einen automatisierten Ablauf. An- 
dererseits erlaubt sie dem Werker einen gewissen Rahmen für individuelle 
Eingriffe in den Ablauf, deren Notwendigkeit sich erst bei der tatsächlichen 
Ausführung zeigt und die zum Zeitpunkt der Erstellung des Arbeitsplans 


noch nicht erkennbar waren. 


Die herkömmliche Vollautomatisierung ist letztlich ein Spezialfall der hier 
vorgestellten Steuerungslogik, die durch Konfiguration einer einzigen Res- 
source pro Aufgabe in Verbindung mit den zeitlichen Abhängigkeiten und 
bei Wegfall des möglichen Eingriffs innerhalb der Montagezelle selbst nach- 
gebildet werden könnte. Die Erweiterungen betreffen also hauptsächlich die 
Möglichkeit mehrerer in Frage kommender Ressourcen pro Aufgabe und die 


optionale Einflussnahme im Shopfloor. 


Zusätzlich bleibt noch einmal hervorzuheben, dass diese Art und Weise der 
Steuerung zwei verschiedene Optionen unterstützt: die zentrale Steuerung 
vom Manufacturing Integration Bus aus, auf die innerhalb der kollaborativen 
Zelle nicht weiter Einfluss genommen werden kann, und die dezentrale Steue- 
rung, die einen Arbeitsplan an die Zelle übermittelt und die weiteren Details 
der Ausführung offen lässt. Im ersten Fall werden die einzelnen Assets un- 
mittelbar vom Manufacturing Integration Bus angesteuert, im zweiten Fall 
ist in der Zelle selbst ein Dispatcher (als Bestandteil des Control Wrappers) 
für die Zuweisung der einzelnen Aufgaben zuständig. Der Werker könnte 
über sein Terminal beispielsweise eine Aufgabe übernehmen, die eigentlich 


dem Cobot zugewiesen war. 


Auch die Steuerung geschieht hier ausschließlich über OPC UA. Mit der 
2019 veröffentlichten OPC UA Companion Specification Robotic (VDMA 
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40010-1) steht zwar grundsätzlich ein Datenmodell auch für die Roboter- 
Anbindung zur Verfügung, dieses zielt aber ausschließlich auf die Darstellung 
von Zuständen ab. Für die eigentliche Ansteuerung eines Roboters muss also 
ein eigenes Datenmodell implementiert werden, das die Skills des jeweiligen 
Roboters berücksichtigt. Für die Validierung wurde ein (bisher unveröffent- 
lichtes) allgemeines Datenmodell des WZL der RWTH Aachen verwendet, 


das für die gängigen Leichtbauroboter anwendbar ist. 


4.6 Persistierung von Prozessdaten 


Während der kollaborativen Montage entstehen in Echtzeit zahlreiche Daten 
an den verschiedenen Teilen der Anlage. Im Sinne des in Abschnitt 4.3 be- 
schriebenen Zyklus sollen diese auf verschiedenen zeitlichen Ebenen (siehe 
Tabelle 4.1) genutzt werden, um die Montage zu optimieren, Fehler zu be- 
heben und neue Produktvarianten besser planen zu können. Dieser Teil der 
Methodik bezieht sich auf die Teilforschungsfrage F4 (siehe Abschnitt 1.3 
auf Seite 9). 


Tabelle 4.1: Zeitebenen bei der Verwertung von Prozessdaten 


Echtzeit-Monitoring Prozessdaten stehen unmittelbar während der lau- 
fenden Montage zur Auswertung durch den Werker 
an der Anlage oder auch automatisierte Monitoring- 
Instrumente zur Verfügung. 


Aggregiert in Echtzeit Wie beim Echtzeit-Monitoring stehen die Daten 
unmittelbar zur Verfügung, werden aber aggregiert 
mit zuvor persistierten Daten dargestellt und ausge- 
wertet. 


Analyse nach der Mon- Die Prozessdaten werden nach Abschluss der Mon- 
tage tage ausgewertet und gewonnene Erkenntnisse in 
spätere Montage-Abläufen berücksichtigt. 
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Der Begriff „Echtzeit“ wird hier verwendet für eine Form der Verarbeitung, 
bei der zwischen der Entstehung der Prozessdaten und deren Verfügbarkeit 
zur Auswertung durch einen Bediener oder Monitoring-Systeme typischer- 
weise nicht mehr Zeit als etwa eine Sekunde vergeht. Eine noch kürzer 
getaktete Verarbeitung ist im Rahmen der hier beschriebenen Methodik nicht 
erforderlich. In anderen Anwendungsszenarien könnte diese natürlich er- 
forderlich und sinnvoll sein, zum Beispiel bei einer Erweiterung auf eine 


Echtzeit-Simulation. 


Die Kommunikation zwischen der kollaborativen Zelle selbst und dem über- 
geordneten, in Abschnitt 4.2 beschriebenen, Manufacturing Integration Bus 
erfolgt ausschließlich über OPC UA (siehe auch Unterabschnitt 2.4.2). Dies 
bietet zahlreiche Vorteile: es muss nur ein Übertragungsweg hergestellt wer- 
den, Sicherheitsfragen sind bereits gelöst und alle weiteren Vorteile der 
Nutzung von OPC UA kommen zum Tragen. Dies gilt sowohl für die zur 
Steuerung (siehe auch Abschnitt 4.5) erforderliche Datenübertragung als 


auch für die Verwertung der Prozessdaten für Monitoring und Analyse. 


Eine kollaborative Zelle beinhaltet im Allgemeinen mehrere Systeme, die 
die verschiedenen Komponenten steuern, z. B. einen oder mehrere Roboter, 
einzelne Werkzeuge wie Greifer oder Schrauber, oder auch weitere Elemente, 
die durch eine oder mehrere SPS angebunden sind. Auf diese Systeme ist 
für die Steuerung ein schreibender Zugriff erforderlich und lesend werden 
Prozessdaten zugänglich. Die Anbindung an den Manufacturing Integration 
Bus kann erheblich erleichtert und vereinfacht werden durch Aggregation des 
OPC-UA-Zugriffs auf alle beteiligten Komponenten wie in Abbildung 4.13 
dargestellt. 


Die einzelnen Komponenten wie SPS, Robotersteuerung, Werkzeugsteue- 
rung oder weitere vergleichbare Systeme haben dabei jeweils einen eigenen 
OPC-UA-Server. Dieser kann in die Hard- und Software der Komponenten 


vom Hersteller derselben bereits integriert sein oder auch zusätzlich installiert 
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Cobot-Zelle 


jos 


Robotersteuerung Werkzeugsteuerung 


Abbildung 4.13: Einheitlicher Zugang zur Cobot-Zelle fiir die Steuerung und den Zugriff auf 
Prozessdaten durch Aggregierung aller Komponenten tiber einen OPC UA 
Aggregierungsserver. 


werden, wenn noch nicht vorhanden. Diese Architektur der von den Herstel- 
lern in SPS und andere Komponenten bereits integrierten OPC-UA-Server 
ist der Hauptgrund fiir die Existenz mehrerer Server innerhalb der Zelle. 
Der in der Abbildung 4.13 zentral dargestellte Aggregierungsserver bildet 
nach außerhalb der kollaborativen Zelle eine einheitliche Schnittstelle und 
spricht nach innen die einzelnen Komponenten an. In den zur Validierung 
verwendeten Implementierungen wurde dazu ein transparenter Aggregie- 
rungsserver verwendet, der von außerhalb der Zelle kommende Requests 
weiterleitet und die Response der angebundenen OPC-UA-Server wieder 
zurückgibt. Es gibt nur wenige entsprechende Produkte am Markt und diese 


haben teilweise auch einen anderen Fokus, so dass die Aggregierung eher 
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eine Nebenfunktion darstellt. Es ist jedoch mit moderatem Aufwand möglich, 
auf Basis eines Frameworks wie Eclipse Milo? einen eigenen transparenten 


OPC-UA-Aggregierungsserver zu implementieren. 


Die hier beschriebene Methodik basiert unter anderem auf der konsequenten 
Nutzung von OPC UA als Kommunikationsgrundlage zwischen Manufactu- 
ring Integration Bus und kollaborativer Zelle. Zum Zweck der Speicherung 
von Prozessdaten ist daher ein OPC-UA-Logger erforderlich, der permanent 
Änderungen an den Werten der beobachteten OPC-UA-Knoten in eine Daten- 
bank protokolliert. Für die zu Testzwecken und die Validierung verwendeten 
Anwendungsfälle wurde ein solcher auf Basis von Eclipse Milo implemen- 
tiert. Die Entwicklung dieses OPC-UA-Loggers steht eng in Zusammenhang 


mit der Beantwortung der Teilforschungsfrage F4. 


Fast alle im Betrieb befindlichen OPC-UA-Server, oft von Herstellern aktu- 
eller Komponenten bereits „mitgeliefert“, wie zum Beispiel der Beckhoff 
SPS, werden im „Data Access“ Modus betrieben. Das heißt jeder Knoten 
hat genau einen Wert, nämlich den aktuellen. Ändert sich dieser, wird der 
vorherige Wert überschrieben und steht nicht mehr zur Verfügung. Dies ist 
der Grund und die Notwendigkeit zur Nutzung eines OPC-UA-Loggers, der 


die Prozessdaten zur späteren Verwendung persistiert. 


Einen Überblick über die möglichen OPC-UA-Datenflüsse gibt Abbil- 
dung 4.14, die auch vergrößert im Anhang zu finden ist und auf die unten 
zurückgekommen wird. In der linken oberen Ecke der Abbildung ist die 
Kollaborative Zelle, in der die Prozessdaten entstehen und über den in der 
Mitte der oberen Reihe dargestellten OPC-UA-Server im Modus Data Ac- 
cess zur Verfügung gestellt werden, auf den sich OPC-UA-Clients (mit den 


entsprechenden Berechtigungen) verbinden können. 


https: //projects.eclipse.org/projects/iot.milo 
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Kollaborative Zelle 
PR 
O Lt  OPCUAServer | 5 OPC UA Client 
SO Data Access 
ES OPC UA 
Werker Cobot 
OPC UA 
& 2 persistiert 
IC: E we OPC UA Client Monitoring Tools 
Datembank 
OPC DA Server m OPC UA Client m Analyse Tools 
Historical Access 
OPC UA 


Abbildung 4.14: Datenfluss zur Persistierung von Prozessdaten mit angeschlossenem Monito- 
ring und Analyse auf Basis von OPC UA. Vergrößerung in Abbildung A.4 auf 
Seite 157. 


Der OPC-UA-Logger stellt einen solchen Client dar, der per Konfiguration 
die relevanten Knoten des (aggregierten) OPC-UA-Servers an der Zelle be- 
obachtet. Dieser ist weiterhin mit einer relationalen Datenbank verbunden, 
in deren Tabellen die Änderungen der Werte geschrieben werden können. 
Kernfunktionalität des OPC-UA-Loggers ist, bei jeder Änderung an einem 
der angebundenen Knoten des OPC-UA-Servers an der Zelle, diesen neuen 
Wert zusammen mit der Serverzeit in die Datenbank zu schreiben. Dabei gibt 
es -zumindest prinzipiell- keine Taktung und kein Polling, sondern nur bei 
Änderung eines Werts erfolgt ein neuer Eintrag in die Datenbanktabelle. Je 
nach Art des in der kollaborativen Zelle stattfindenden Montageprozesses und 
der angebundenen Sensoren und Assets kann die resultierende Datenmenge 
sehr gering oder auch sehr groß sein und im Extremfall auch die Einsatz- 
grenzen eines RDBMs überschreiten. In diesem Fall könnten Techniken aus 


dem Bereich des Datastream Processing angewandt werden, was jedoch bei 
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den im Rahmen dieser Arbeit implementierten Systemen nicht erforderlich 


war. 


Auch technischer Sicht besteht keine Notwendigkeit einer räumlichen Nä- 
he zwischen Kollaborativer Zelle und Prozessdatenspeicher, da der OPC- 
UA-Standard alle erforderlichen sicherheitsbezogenen Fähigkeiten bereits 
beinhaltet. Sowohl die Authentifizierung und die Vertraulichkeit, aber auch 
die Integrität können in einfacher Weise implementiert werden. So spricht 
aus technischer Sicht auch nichts gegen die Persistierung der Prozessdaten 
in Cloud-Lösungen, die als separates Produkt angeboten werden könnten. 
Voraussetzung ist natürlich die Anbindung aller relevanten Datenquellen an 
den OPC-UA-Server der Zelle selbst. 


Sind die historischen Werte erst einmal in der Datenbank gesichert, gibt es 
mehrere Wege, diese wieder nutzbar zu machen. Ein naheliegender Weg ist 
der direkte Zugriff von Monitoring- oder Analyse-Werkzeugen auf die Daten- 
bank selbst. Eine Alternative dazu stellt die Bereitstellung historischer Daten 
auf Basis des OPC UA „Historical Access“ Modes dar, der in Teil 11 der 
OPC UA Spezifikation beschrieben ist (OPC Foundation 2015). Dieser Fall 
ist in Abbildung 4.14 links unten dargestellt und setzt die Implementierung 
eines weiteren OPC-UA-Servers voraus, der allerdings im Modus „Histo- 
rical Access“ betrieben wird. Wesentliches Merkmal einer Abfrage dieser 
Servers ist neben dem Namen des Knotens ein zeitliches Intervall, in dem die 
zurückgegebenen Werte liegen sollen. Somit stellt der OPC UA Historical 
Access Server eine standardisierte Schnittstelle zur sicheren Bereitstellung 


historischer Prozessdaten dar. 


Eine weitere Möglichkeit bietet dieses Logging für in den Montageprozess 
integrierte Prüfungen, deren Ergebnisse auf diesem Weg einfach und stan- 
dardkonform gesichert und in Monitoring und Analyse verwendet werden 


können. 
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Die hier beschriebene Teilmethodik zur Persistierung der Prozessdaten kolla- 


borativer Montagesysteme beantwortet die Teilforschungsfrage F4. 


4.7 Monitoring und Analyse kollaborativer 
Prozesse 


In den meisten Fällen ist innerhalb der kollaborativen Zelle der Mensch 
derjenige, der aufgrund seiner großen Flexibilität die Kontrolle über das 
Geschehen ausübt und bei Abweichungen vom geplanten Ablauf eingrei- 
fen muss. Dazu benötigt er aktuelle Informationen über den Zustand aller 
Komponenten der Zelle. An seinem Werker-Terminal (als HMI) sollen ihm 
daher Informationen zum Ablauf und aktuellen Zustand der Montage in 
schnell erfassbarer und übersichtlicher Art und Weise zugänglich sein. Dies 
ermöglicht ein (Condition) Monitoring der kollaborativen Montage, das in 
diesem Kapitel näher beschrieben werden soll. In der Literatur findet man 
dazu einige Ansätze (Pethig, Niggemann und Walter 2017), die aber nicht 


auf die besonderen Bedingungen der kollaborativen Montage eingehen. 


Die Grundlage für das Monitoring bilden die in den vorhergehenden Kapiteln 
beschriebenen Methoden zur Erfassung und Persistierung der Prozessdaten. 
Prinzipiell könnte ein Monitoring nur auf den jeweils aktuellen Zustandswer- 
ten aus der Zelle aufgebaut sein. Nimmt man aber Daten aus einer kurzen 
gerade vergangenen Zeitspanne hinzu, erreicht man eine größere Informati- 
onstiefe, z. B. bei der Entdeckung von Trends. Weiterhin können auf Basis der 
hier vorgestellten Weise der Beschreibung und Steuerung der kollaborativen 
Zelle auch deren Struktur und die Informationen aus der Simulation hinzuge- 
zogen werden, um noch aussagekräftigere Parameter für das Monitoring zu 
generieren. Einige Beispiele dazu werden weiter unten gegeben. Der Fluss 


der Prozessdaten auf Basis von OPC UA für Zwecke des Monitoring ist in 
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Abbildung 4.14 auf Seite 105 zusammengefasst. Eine praxisnahe Alternative 
ist die Anbindung direkt an die Datenbank (in der Abbildung Mitte links). 


Neben allgemeinen Parametern gibt es einige spezifische, die unter dem 
Aspekt der Kollaboration und in Verbindung mit der durch die Simulati- 
on entstandenen Planung von besonderem Interesse sind. Dies sind unter 


anderem: 


Zustände 

Der Zustand der gesamten Cobot-Zelle, aber auch der Zustand einzelner 
Komponenten, z.B. Roboter oder Greifer, kann ein simpler Hinweis auf Ab- 
weichungen vom geplanten Ablauf sein. Sinnvolle Werte können Zustands- 
beschreibungen wie z. B. „waiting“ oder „busy“ sein. Auch der Vergleich mit 
den im Arbeitsplan aus der Simulation festgelegten Zuständen ist von Interes- 
se, da Abweichungen von den Ergebnissen der Simulation ein unmittelbares 


Eingreifen des Werkers erforderlich machen kann. 


Durchlaufzeiten 

Ein Ergebnis der Simulation ist die erwartete Bearbeitungszeit pro Aufga- 
be. Hier bietet sich ein Vergleich mit der tatsächlich aktuell verstrichenen 
Bearbeitungszeit an. 


At = tsim — tact 


mit tsim = Bearbeitungszeit gemäß Simulation 


tact = tatsächlich verstrichene Bearbeitungszeit 
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Positive Werte können als Normalfall betrachtet werden, negative Werte ab 
einem gewissen Schwellenwert können auf Probleme hinweisen. Dies kann 


näher quantifiziert werden durch Einführung eines Toleranzkoeffizienten: 


tim = tsim ` Cr — tact 


mit tsim = Bearbeitungszeit gemäß Simulation 
tact = tatsächlich verstrichene Bearbeitungszeit 


ct = Toleranzkoeffizient (z. B. 1,3) 


Wird tiim negativ, kann dies als Indikator für Abweichungen verwendet und 


ggf. ein Alarm ausgelöst werden. 


Aufteilung zwischen Roboter und Mensch 

Der jeweils vom Cobot und vom Werker übernommene Anteil der Aufgaben 
kann im Verhältnis zueinander ebenfalls aussagekräftig sein, insbesondere 
im Vergleich mit den diesbezüglichen Ergebnissen der Simulation. Zunächst 
kann die Differenz zwischen bis zum jeweiligen Arbeitsschritt geplanten und 
tatsächlich ausgeführten Aufgaben (Anzahl), sowohl für den Cobot als auch 


für den Werker, berechnet werden: 
An = Nsim — Nact 
mit nsin = Anzahl Aufgaben laut Simulation 


Nact = tatsächlich durchgeführte Aufgaben 


Darauf basierend und ebenfalls mit einem angemessen definierten Toleranz- 


koeffizienten versehen, können Abweichungen schnell erkannt werden. 
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Ergebnisse von Prüfungen 

Beinhaltet die Cobot-Zelle auch Prüfeinrichtungen, kann das Ergebnis der 
Prüfung dem Werker direkt angezeigt werden, so dass er unter Umständen 
Zusammenhänge erkennt, die zu einer unmittelbaren Änderung der Ausfüh- 


rungsplanung führen müssten. 


Trends 

Bei wiederholter Ausführung einer Aufgabe, zum Beispiel bei Bearbeitung 
eines Auftrags mit einer Stückzahl größer als etwa 10, können Trends der 
oben beschriebenen und weiterer Werte angezeigt werden. Steigende Bear- 
beitungszeiten zum Beispiel können auf Probleme an der Anlage oder auch 


Ermüdung des Werkers hinweisen. 


Die Auflistung dieser Parameter ist nur exemplarisch zu verstehen, da im 
jeweiligen konkreten Anwendungsfall im Allgemeinen zahlreiche weitere 
hinzukommen werden. Mit diesem Ansatz wird eine Annäherung an die 


Antwort auf Teilforschungsfrage F5 angestrebt. 


Die Darstellung aller für das Monitoring in der Cobot-Zelle relevanten Werte 
erfolgt über ein grafisch sinnvoll aufbereitetes Dashboard durch intuitive Gra- 
fiken mit assoziativen Farben. Dieses wird dem Werker an seinem Terminal 
angezeigt und soll ihm ermöglichen, den aktuellen Zustand aller Komponen- 
ten und des gesamten Arbeitsablaufs schnell und einfach zu erfassen und 


Abweichungen zu erkennen. 


Während das Monitoring sich einerseits auf sehr aktuelle Prozessdaten be- 
schränkt und andererseits auch die Möglichkeit der sofortigen Reaktion zum 
Ziel hat, ist die ausführlichere Analyse der aufgezeichneten Prozessdaten und 
die Umsetzung der daraus gezogenen Schlussfolgerungen eine Engineering- 
Aufgabe (siehe auch Abbildung 4.15). 
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Abbildung 4.15: Unterschied zwischen Monitoring und Analyse bei der kollaborativen Monta- 
ge. 


Die zeitliche Skala des Monitoring bewegt sich innerhalb der Montage ei- 
ner einzelnen Produktinstanz oder maximal innerhalb eines Auftrags. Die 
Analyse erlaubt einen größeren Zeithorizont über mehrere Aufträge oder 
noch längere Zeiträume. Durch die damit entstehenden größeren Stichpro- 
benumfänge und längeren Zeitreihen wird die Anwendung fortgeschrittener 
statistischer Methoden der deskriptiven Statistik und der Zeitreihenanalyse 


möglich. 


Einen umfassenden Überblick über Verfahren zur statistischen Analyse von 
industriellen Prozessdaten (wie z. B. die Hauptkomponentenanalyse und an- 
dere) gibt S. Yin u.a. (2014). 


Die in diesem Kapitel beschriebenen Verfahren beantworten die Teilfor- 
schungsfrage F5 nach der Überwachung der Prozessdaten während der kol- 
laborativen Montage und die Teilforschungsfrage F6 nach der Analyse der 


Prozessdaten im Hinblick auf weitere Engineering-Zyklen. 
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4.8 Zusammenfassung 


Die in diesem Kapitel vorgestellte Methodik für das Informationsmanage- 
ment bei der kollaborativen Montage variantenreicher Produkte besteht aus 
mehreren Teilen, deren verbindendes Element und „Rückgrat“ der Manufac- 
turing Integration Bus (MIB) ist. Er integriert die heterogenen Datenflüsse 
und -formate und speichert alle Daten zentral. Der MIB erhält Daten von 
Standardsystemen wie dem ERP oder dem PDM, stellt die Verbindung zur 
Simulation dar, steuert die Montage in der Cobot-Zelle und verarbeitet die 


Prozessdaten. 


Produkt und Anlage durchlaufen von ihrer Entstehung bis zu ihrer Entsorgung 
einen jeweils eigenen Lebenszyklus. Im Schnittpunkt findet die Montage des 
Produkts statt. Die Anlage ist zu einer Rekonfiguration in der Lage und so 
kann auch jeder einzelne Montagevorgang eine Grundlage für weitere Mon- 
tagevorgänge werden. Durch die möglichst vollständige virtuelle Abbildung 
der Anlage in AutomationML entsteht der Digitale Zwilling. Er bildet die 
Grundlage für die Simulation eines Montagevorgangs, die die Sicherheit des 
Werkers und der Anlage erhöht und wiederum Basis für die Generierung des 


detaillierten Arbeitsplans ist. 


Eine weitere Aufgabe des MIB ist die Steuerung der kollaborativen Montage, 
entweder zentral oder auch dezentral mit Einflussmöglichkeiten innerhalb 
der Cobot-Zelle. Diese vollständig über OPC UA abgebildeten Steuerungs- 
abläufe basieren auf dem Ergebnis der Simulation, insbesondere den Robo- 
terbahnparametern und erwarteten Werten, z.B.den Durchlaufzeiten. Die 
bei der Montage beobachteten Prozessdaten, ebenfalls ausschließlich per 
OPC UA übertragen, persistiert der MIB und stellt sie für Monitoring- und 
Analysezwecke zur Verfügung. Das kurzfristige Monitoring ermöglicht Ein- 
griffe in laufende Montageprozesse bei unerwartetem Verhalten einer der 


Komponenten und die langfristige Analyse von Prozessdaten über mehre- 
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re Montagevorgänge oder Aufträge hinweg bildet die Grundlage für die 


Optimierung der Montage im Engineering. 
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Im vorherigen Kapitel 4 wurde eine Methodik für das Wissens- und Pro- 
zessmanagement bei der kollaborativen Montage variantenreicher Produkte 
vorgestellt. Mit dem Manufacturing Integration Bus im Zentrum und Me- 
thoden für die Verbindung zur Simulation, die Steuerung der kollaborativen 
Zelle, das Monitoring, die Persistierung von Prozessdaten und die Auswer- 
tung der Prozessdaten bildet sie eine Grundlage für den Aufbau und Betrieb 


kollaborativer Montagesysteme. 


Die Gesamtmethodik soll in diesem Kapitel validiert werden. Dazu wird 
in Abschnitt 5.1 zunächst die Problemstellung erneut aufgegriffen und die 


grundsätzliche Vorgehensweise bei der Validierung näher erläutert. 


Dann werden in den Abschnitten 5.2 bis 5.4 insgesamt drei Anwendungsfälle 
vom Minimal-Demonstrator bis zur Anwendung an einer industriellen Anlage 


vorgestellt. 


5.1 Vorgehensweise zur Validierung 


Während der Entwicklung der in Kapitel 4 beschriebenen Methodik wurden 
mehrere voneinander verschiedene Testfälle implementiert, die ein breites 
Spektrum an Tests ermöglichen, die wiederum zur Weiterentwicklung der 
Methodik beigetragen haben. Zusätzlich wurde die bereits auf diesem Weg er- 


arbeitete Methodik in einem industriellen Anwendungsfall implementiert. 
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Zur Validierung wird eine Methodik auf ihre Eignung hin geprüft, ob sie die 
vorgesehenen Ziele erreicht, und „die Bestätigung durch objektiven Nachweis 
erbracht, dass die Anforderungen für eine bestimmte Anwendung oder einen 
bestimmten Gebrauch erfüllt sind“ (ISO 9000). 


Das Ziel dieser Arbeit ist die Bereitstellung eines an die kollaborative Mon- 
tage variantenreicher Produkte angepassten Informationsmanagements. Die 
hier vorgestellte Methodik ist grundsätzlich im Rahmen der beschriebenen 
Anwendungsbereiche und Grenzen allgemeingültig und kann daher in den 


verschiedensten Szenarien kollaborativer Montage zum Einsatz kommen. 


Eine Fallstudie definiert Schramm (1971) cit.in R. K. Yin (2018) so: 


„Ihe essence of a case study, the central tendency among all 
types of case study, is that it tries to illuminate a decision or set 
of decisions: why they were taken, how they were implemented, 


and with what result.“ 


In diesem Sinne folgt die Betrachtung von drei verschiedenen Fällen, in 
denen jeweils Teilbereiche der Methodik implementiert und auf ihre Eignung 


hin getestet wurden. 


Aus verschiedenen Gründen (zeitliche Beschränkungen, Simulationsaufwand, 
etc.) konnten nicht alle Teilbereiche der Methodik an allen drei Fallbeispie- 
len erprobt werden (siehe auch Tabelle 5.1). Daher wird in den folgenden 
Kapiteln nicht bei allen Fallbeispielen auf alle Aspekte eingegangen. 


5.2 Demonstrator mit minimalem 
Funktionsumfang 


Als einfache und unkomplizierte Methode zum Testen einzelner Teile der 


gesamten Methodik für das Informationsmanagement bei der kollaborativen 
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Tabelle 5.1: Implementierte Teile der Methodik in den unterschiedlichen Fallbeispielen 


Minimal- Erweiterter Industrielle 
Demonstrator | Demonstrator | Anlage 
Manufacturing wë v 
Integration Bus 


Digitaler Zwilling = 


v v 
Anbindung wi v 
Simulation 
Steuerung v v 
Persistierung v 


Monitoring 


2 SS SN 


Analyse 


Montage hat sich ein Miniatur-Demonstrator mit minimalem Funktionsum- 
fang erwiesen, dessen Aufbau und Funktionsweise in diesem Kapitel näher 
beschrieben werden soll. Er dient als Laborumgebung zur Veranschaulichung 
der Abläufe der kollaborativen Montage auf eine stark vereinfachte und auf 
das Minimum reduzierte Art und Weise (Schneider 2019). 


Einen Gesamtüberblick des Minimal-Demonstrators gibt die Abbildung 5.1. 
In der oberen Hälfte ist der 2-Achs-Roboter erkennbar, der auf der Grundplat- 
te fixiert ist. Er entspricht modellhaft einem Leichtbauroboter (wie z. B. dem 
Universal Robots UR 5 oder dem Kuka iiwa) an einem industriellen kol- 
laborativen Arbeitsplatz, wenn auch mit reduzierter Anzahl an Achsen. In 
der unteren Hälfte des Bildes sind mehrere Ablageplätze für das Modell- 
Werkstück, einige Lichtschranken und ein Minimal-HMI in Form einiger 


Signallampen und eines Tasters sichtbar. 
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le 


Abbildung 5.1: Gesamtüberblick über den Fischertechnik Minimal-Demonstrator zur Veran- 
schaulichung kollaborativer Montage. Vergrößerung in Abbildung A.5 auf Sei- 
te 158. 


An Ende des Roboterarms befindet sich ein pneumatischer Greifer, der Kom- 
pressor und die übrigen Teile der Pneumatik sind blau und daher leicht 
auffindbar. 


Gesteuert werden die einzelnen Komponenten einschließlich Roboter und 
Greifer über Fischertechnik Robotics TXT Controller, die in ihrer Funkti- 
onsweise industriellen SPS sehr ähnlich sind (siehe Abbidlung 5.3). Als 
selbständige Linux-Systeme mit eigener Bedienoberfläche unterstützen sie 
zahlreiche Schnittstellen. Über USB ist einer der beiden Controller mit einem 


Raspberry Pi verbunden und über die Python-Bibliothek ftrobopy! können 


l https://github.com/ftrobopy/ftrobopy 
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Abbildung 5.2: Pneumatischer Greifer am Fischertechnik-Minimal-Demonstrator. 


die einzelnen Ein- und Ausgänge der Controller angesteuert werden. Als 
Modell-HMI gibt es einige Leuchtanzeigen, die den Betrieb des Roboters 
signalisieren und den Werker zu einer Eingabe auffordern. Dieser kann durch 


Betätigen eines Tasters den Abschluss seiner Aufgabe bestätigen. 


Oberhalb des gesamten Minimal-Demonstrators ist eine Webcam angebracht, 
die die Beobachtung der Abläufe auch aus der Ferne gestattet. Neben der 
Bereitstellung dieses Videostreams bildet der Raspberry Pi auch die Platt- 
form für den zentralen OPC-UA-Server, der die einzige Schnittstelle der 
Demonstrator-Cobot-Zelle nach außen bildet. Der OPC-UA-Server wurde 
auf Basis des Eclipse Milo? OPC UA Frameworks entwickelt und die Knoten 


? https: //projects.eclipse.org/projects/iot.milo 
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Abbildung 5.3: Die Robotics TXT Controller am Fischertechnik Minimal-Demonstrator. 


des implementierten Informationsmodells entsprechen den einzelnen Assets 
des Modells. 


Eclipse Milo ist eine Open Source Implementierung von OPC UA, die zum 
Zeitpunkt der Erstellung dieser Arbeit in der Version 0.3.8 vorliegt und bereits 
die wesentlichen Teile des Stacks enthält, ebenso wie die darauf basierenden 
SDKs für Client und Server. Insbesondere die sicherheitsrelevanten Kom- 
ponenten von OPC UA sind bereits vollständig implementiert, so dass auf 


diesem Gebiet keine Kompromisse eingegangen werden mussten. 


Da der Fokus bei diesem Minimal-Demonstrator nicht auf komplexen Ar- 
beitsabläufen liegt, reicht ein minimalistisches Kollaborativszenario, das nur 


aus den folgenden drei Schritten besteht: 


1. Holen eines Werkstücks durch den Roboter 
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2. Bearbeitung des Werkstücks durch den Werker 


3. Zurücklegen des Werkstücks durch den Roboter 


Bei strenger Anwendung der in Unterabschnitt 2.2.1 auf Seite 22 eingeführten 
Begriffe handelt es sich also nicht um eine echte Kollaboration, sondern 
um Synchronisation oder Kooperation, da Roboter und Mensch zu keinem 


Zeitpunkt gleichzeitig im selben Arbeitsraum aktiv sind. 


Überblicksartig ist die informationstechnische Architektur des Minimal- 
Demonstrators in Abbildung 5.4 zusammengefasst. Auf der oberen Ebene, 
auch räumlich getrennt von der Cobot-Zelle, kann über einen Browser auf den 
Videostream und (links unten) über einen OPC-UA-Client auf die Steuerung 


und den Systemzustand zugegriffen werden. 


Stream Server 
Browser . pe 
auf Raspberry Pi 
ts 
u Be Webcam 


a 


OPC UA Client OPC UA Servar | s FT TXT Controller 


auf Raspberry Pi Le 
I, 
Ampel/Taster 2 


Werker 


Abbildung 5.4: Architektur-Überblick der Komponenten des Fischertechnik Minimal- 
Demonstrators. 


Bei dem Minimal-Demonstrator wurden die Simulation und der Manufac- 
turing Integration Bus nicht implementiert. Stattdessen wurde mit Hilfe 
einer eigens entwickelten Oberfläche (siehe Abbildung 5.5) eine einfache 
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Zusammenstellung eines Arbeitsplans ermöglicht. Dazu sind alle ausführ- 
baren Aufgaben -am Demonstrator sind es nur wenige- als Knoten des 
OPC-UA-Servers modelliert, werden dort vom Tool erkannt und können zu 
Arbeitsplänen zusammengestellt werden. Dieser Arbeitsplan kann dann auch 


direkt aus dem Planungswerkzeug heraus ausgeführt werden. 


eee MSC Lab Cobot Control 
Worker Cobot 
PaintBlack MoveToGet © | MoveToStart: 
Pick MoveToGet 


MoveToPut: 
Pick 


PaintBlack Release 


MoveToPut 


Release 


Connect Disconnect Add block Remove block Save Load Run 


Abbildung 5.5: Grafische Oberfläche zur kollaborativen Arbeitsplanung auf OPC-UA-Basis. 


Die Prozessdaten werden von einem ebenfalls auf Basis von Eclipse Milo 
im Rahmen dieser Arbeit entwickelten OPC-UA-Logger persistiert, der bei 
jeder Änderung an einem der konfigurierten Knoten des OPC-UA-Servers 
einen Eintrag in die angebundene PostgreSQL-Datenbank schreibt. 


Das Beispiel in Abbildung 5.6 zeigt die erfassten Werte des Zustands des 
Roboters (binär, aktiv oder nicht aktiv, hier codiert als Integer) zu einem 
bestimmten Zeitpunkt. Zu beachten sind hier die zum Teil abweichenden 
Zeitstempel der eigentlichen Datenquelle („Source Timestamp“, hier: Ro- 
botersteuerung) und OPC-UA-Server („Server Timestamp“), wobei für die 
meisten Auswertungen die Verwendung des ersteren sinnvoller erscheint. Da- 


bei ist wichtig, dass alle „Source Timestamps“ von der selben Uhr stammen 
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sollten, um eine zeitbezogene Auswertung mehrerer Variablen sinnvoll zu 


ermöglichen. 


SS public.robot/postgres/postgres@PostgreSQL 10 (x86) 
Query Editor Query History 


1 SELECT * FROM public.robot 


Data Output Explain Messages Notifications 


value servertime i ; sourcetime ; ; a 
4 integer timestamp without time zone timestamp without time zone 
2 1 2019-10-28 20:54:17 2019-10-28 20:54:17 
3 0 2019-10-28 20:54:37 2019-10-28 20:54:37 
4 1 2019-10-28 20:54:48 2019-10-28 20:54:48 
5 D 2019-10-28 21:01:08 2019-10-28 21:01:07 
6 1 2019-10-28 21:02:27 2019-10-28 21:02:27 
7 D 2019-10-28 21:02:47 2019-10-28 21:02:47 
8 1 2019-10-28 21:02:55 2019-10-28 21:02:55 
9 D 2019-10-28 21:03:17 2019-10-28 21:03:17 
10 1 2019-10-28 21:06:49 2019-10-28 21:06:49 


Abbildung 5.6: Vom OPC-UA-Logger gefüllte Tabelle mit Zustandswerten des Roboters. 


m Vergleich mit einem simpleren Polling-Ansatz mit Erfassung des Roboter- 
zustands in bestimmten Intervallen entsteht durch das Logging ausschließ- 
lich bei Änderungen eine wesentlich geringere Datenmenge. Am Minimal- 
Demonstrator wurden neben dem Aktivitätszustand des Roboters und des 
Werkers auch die Zustände der Signale und der gesamten Zelle erfasst, um ex- 
emplarisch die Funktionsweise des OPC-UA-Loggers und die Möglichkeiten 
in Monitoring und Analyse zu testen (siehe auch Abbildung 5.7). 


Ein mit Grafana? entwickeltes Dashboard zeigt den jeweils aktuellen Zustand 
der Zelle an. Mit den über mehrere simulierte Montagezyklen erhobenen 


Daten wurden mit R* einige Analysen berechnet und grafisch dargestellt. 


3 https: //www.grafana.com 
4nttps://www.r-project.org 
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LE! Prosys OPC UA Client 
© MSCLab OPC UA Server | + 
Running opc.tcp://msclab.dyndns1.de:4840/msclab -- urn:see:msclab:c15a2e20-0ca9-4c7b-9812-6e8297e2f328 ~*~ x ci Å kokomo 
© Search Attributes and References | Data View X | + 
Y CP Objects ` Subscription Enabled Y Publishing Interval (in milliseconds) ` 100 + Subscription Settings... 
r E Cobot 
# ` Nodel DisplayName Value DataType SourceTimesta.. Serverfimestam.. StatusCode Monit.. Cap 
v SC Lab deld l fal H h 
> © Cell State o Traffic Light 0 Integer 23.03.2020 14:... 23.03.2020 14:3... GOOD (0x... Repor... 
e 1 Robot o Integer 23.03.2020 14:... 23.03.2020 14:3... GOOD (0x... Repor... 
> @ Robot 2 Switch o Integer 23.03.2020 1. 23.03.2020 14:3... GOOD (0x... Repor... 
» © Switch 3 Synthinteger 829... Integer 23.03.2020 1 23.03.2020 14:4... GOOD (0x... Repor... 
Weer 4 =Cellstate Cell State o Integer 23.03.2020 1 23.03.2020 14:3... GOOD (0x... Repor... 
S ynthBoolean 5 ns=2;s=SynthBoolean SynthBoolean false Boolean 23.03.2020 1 23.03.2020 14:4... GOOD (0x... Repor... 
© Synthinteger 6 ‚=Worker Worker o Integer 23.03.2020 14:... 23.03.2020 14:3... GOOD (Ox... Repor... 
> @ Test Node 7 ns=2;s=testnode Test Node -0.0... Double 23.03.2020 14:... 23.03.2020 14:4... GOOD (0x... Repor... 


> © Traffic Light 
> © Worker 
» @ Server 
> E state 
> E Worker 
> Mi Types 
> I Views 


Abbildung 5.7: Darstellung der OPC-UA-Knoten und ihrer aktuellen Werte im Client. 


In Abbildung 5.8 ist exemplarisch für die zur Verfügung stehenden um- 
fangreichen Analysemöglichkeiten die mit Hilfe der geloggten Prozessdaten 
berechnete Bearbeitungszeit des Werkers innerhalb eines Montagevorgangs 
wiedergegeben, links als Zeitreihe, rechts die daraus abgeleitete Häufigkeits- 
verteilung. Die Betrachtung der Messwerte als Zeitreihenanalyse erlaubt zum 
Beispiel die Untersuchung auf Trends wie die in der Abbildung trotz des 
geringen Umfangs der Zeitreihe bzw. Stichprobe erkennbare Zunahme der 
Bearbeitungszeit. Derartige Auswertungen unterstützen das Engineering und 
können Ausgangspunkt der Suche nach der Ursache beobachteter Anomalien 


sein. 


Am Minimal-Demonstrator konnten die in Tabelle 5.1 auf Seite 117 markier- 


ten Teile der Gesamtmethodik erfolgreich erprobt werden. 


Einzelne Teile dieses Unterkapitels wurden bereits in Schneider (2019) ver- 
öffentlicht. 
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Bearbeitungszeit des Werkers Häufigkeitsverteilung 


"| / la 
| N 


Absolute Häufigkeit 
2 
f 


Montage Nr. Zeit [s] 


Abbildung 5.8: Beispielhafte einfache statistische Analyse der Bearbeitungszeit des Werkers 
am Minimal-Demonstrator. 


5.3 Demonstrator mit erweitertem 
Funktionsumfang 


Im Rahmen des durch das Bundesministerium für Bildung und Forschung 
geförderten Projekts KoKoMo wurde am Werkzeugmaschinenlabor (WZL) 
der RWTH Aachen ein Demonstrator für kollaborative Montage aufgebaut. 
Die in Kapitel 4 beschriebene Methodik konnte an diesem Demonstrator 


teilweise (siehe auch Tabelle 5.1) implementiert und getestet werden. 


Der Demonstrator ist ein Arbeitsplatz mit auf Tischhöhe befestigtem Leicht- 
bauroboter vom Typ KUKA LBR iiwa, einem Werker-Terminal und einem 


Werkzeugwechselsystem (siehe Abbildung 5.9). 


Zur Steuerung diverser Aktoren ist eine Beckhoff SPS mit integriertem OPC- 
UA-Server angeschlossen, die Robotersteuerung erfolgt über einen sepa- 


raten PC und die vom Hersteller zur Verfügung gestellte Software. Einen 
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Abbildung 5.9: Ansicht des am Werkzeugmaschinenlabor der RWTH Aachen aufgebauten Ko- 
KoMo Demonstrators. Foto: Simon Roggendorf (WZL RWTH Aachen). Ver- 
größerung in Abbildung A.6 auf Seite 159. 


Gesamtüberblick über die beteiligten Systeme und ihre Verbindungen gibt 
Abbildung 5.10. 


Bei dieser Implementierung der Methodik befindet sich der Manufacturing 
Integration Bus als zentraler Knoten im Mittelpunkt der angebundenen Syste- 
me. Im oberen Bereich der Abbildung befindet sich die am Bremer Institut für 
Strukturmechanik und Produktionsanlagen (BIME) der Universität Bremen 
realisierte Simulation, die vom Manufacturing Integration Bus die Grobpla- 
nung erhält und eine detailliertere Planung der Montage zurückgibt. Die 
Kommunikation erfolgt hier über ein eigens definiertes XML-Format. In 
Richtung der kollaborativen Zelle (in der Abbildung nach unten) sind alle 
Systeme per OPC UA angebunden. 


Die an die SPS (hier von Beckhoff) angeschlossenen Sensoren und Aktoren 
können mit geringem Aufwand per OPC UA angesprochen werden, da die 


SPS einen bereits vom Hersteller angebundenen OPC-UA-Server beinhaltet. 
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Industrial 
ad Simulation Ph HoloLens 
pror | bzw. HTC Vive 


REST API REST API (Automation ML) 
Geometry & Kinematics 


Manufacturing Integration Bus 


OPC UA Client OPC UA Server | 
‘OPC UA Binary: OPC UA Server 
Cz] 
OPC UA Binary REST API (Automation) —| 
OPC UA Binary——_ OPC UA Client 


WZL-GUI 
(Werker-Terminal) 


OPC UA Server DEC UA Binary = 
I 
OPC UA Robot Spec 4 Gateway 1 Text TCP/IP, _ 
IndustriaIPC fo (proprietar) 
Beckhoff SPS (C# Steuerung) OPC UA Robot Spe Roboter 

Hex TCP/IP (proprietar) 

1 

10 10 
| Open Data Protocol (DESOUTTER) 
Sensoren Aktoren Greifer 


Schrauber 


Abbildung 5.10: Systemüberblick der Komponenten am Demonstrator mit erweitertem Funk- 
tionsumfang. 


Schwieriger stellt sich die Anbindung des Roboters und seiner Steuerung 
dar. Zwar steht mit der OPC UA Companion Specification Robotics ein 
standardisiertes Informationsmodell für Roboter zur Verfügung, dass her- 
stellerunabhängig ist. Jedoch eignet sich dieses nur für die Darstellung des 
Zustands des Roboters, jedoch nicht für die Steuerung, da die hierzu benö- 
tigten Komponenten in der Companion Specification nicht vorgesehen sind. 
Eine auf CollabML basierende Beschreibung des Arbeitsplans ermöglicht 
an diesem Demonstrator die Verteilung der Aktionen auf die beteiligten 


Komponenten der kollaborativen Zelle. 
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A bime 


Integration Bus Simulation 


SEEBURGER 


BUSINESS INTEGRATION 


Client 


Status Pushen 


eee Skills anbieten 


Cobot-Server 
Port 48030) 


TCP/JSON 


TCP/JSON 


Sensoren Aktoren 


Abbildung 5.11: Systemarchitektur zur Steuerung und Rückmeldung von Prozessdaten am De- 
monstrator mit erweitertem Funktionsumfang. Abbildung: Simon Roggendorf 
(WZL RWTH Aachen). Vergrößerung in Abbildung A.7 auf Seite 160. 


Abbildung 5.11 zeigt die beteiligten Komponenten mit dem Schwerpunkt auf 
dem Aspekt der Steuerung. Sie ist nach außerhalb der Zelle gekapselt und 
ausschließlich per OPC UA ansprechbar. Auf diesem Weg wird einerseits der 
aktuelle Zustand zum Manufacturing Integration Bus zur Verfügung gestellt, 


andererseits von dort auszuführende Arbeitspläne entgegengenommen. 


Ein vom Manufacturing Integration Bus über OPC UA eintreffender Montage- 
Auftrag wird vom zentralen OPC-UA-Server der Zelle an einen Dispatcher 
übergeben, der mit den einzelnen Assets innerhalb der Zelle über ein TCP/IP- 
Netz verbunden ist und die einzelne Aufgabe für eine Komponente als JSON- 
Snippet weitergibt. Die Zustände werden wiederum zum OPC-UA-Server 
übertragen und dort für den Zugriff durch den Manufacturing Integration 
Bus bereitgestellt. Ein OPC-UA-Logger als Bestandteil des Manufacturing 
Integration Bus schreibt jede Änderung der Zustandsdaten der Zelle in eine 


angeschlossene Datenbank wie in Abschnitt 4.6 auf Seite 101 beschrieben. 
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5.4 Industrielle Anlage in Inbetriebnahme 


Mit Hilfe dieses Demonstrators mit erweitertem Funktionsumfang konnten 


wesentliche Teile der gesamten Methodik erfolgreich getestet werden. 


5.4 Industrielle Anlage in Inbetriebnahme 


Ein wesentlicher Bestandteil des bereits oben mehrfach erwähnten Projekts 
KoKoMo war die Erprobung der im wissenschaftlichen Labor-Kontext erar- 
beiteten Methoden an drei konkreten Fällen aus der industriellen Anwendung. 
Eines der drei Anwenderunternehmen war die Euchner AG in Leinfelden- 
Echterdingen, ein mittelständischer Hersteller von Sicherheitseinrichtungen. 
Bei dem für die kollaborative Montage ausgewählten Produkt handelt es sich 
um ein Modul, das einerseits in Kombination mit anderen Teilen die Her- 
stellung zahlreicher Varianten einer Sicherheitskäfig-Zuhaltung („MGB2“) 
erlaubt, andererseits selbst aber ebenfalls modular („Submodul“) aufgebaut 
ist und in mehreren hundert Varianten hergestellt werden kann (siehe auch 
Abbildung 1.1 auf Seite 6). Die Varianten unterscheiden sich durch die Kom- 


bination der drei möglichen Tastelemente. 


Wie in Abschnitt 2.2 auf Seite 20 beschrieben übernimmt der Roboter auch 
in diesem Fall die stabilen, sich wiederholenden Aufgaben, während der 
Mensch die komplexeren individuellen Aufgaben übernimmt. Dabei wird 
die Gesamtdurchlaufzeit verkürzt durch die Errichtung von Pufferzonen, in 
denen Werkstücke zwischen Arbeitsschritten abgelegt werden. Dies trägt zu 


einer besseren Auslastung und damit Wirtschaftlichkeit bei. 


Damit ergeben sich die folgenden Abläufe (Quelle: Euchner AG): 


Ablaufbeschreibung Mensch 


e Individuelle Montage der Rafix-Elemente 
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e Fügen (Nur Auflegen) der Leiterplatte 


e Vormontiertes Modul in „Tray vormontiert“ (Pufferzone Nr. 1) ablegen 


Ablaufbeschreibung Roboter + Anlagentechnik + Prüftechnik 


e Vormontiertes Modul aus „Tray vormontiert“ abholen und alle Statio- 


nen durchreichen 
e Einlegen in „Dichtigkeitsprüfvorrichtung“ 


e NUR wenn „Dichtigkeitsprüfvorrichtung = Leer“, sonst ablegen in 


„Tray geprüft“ 


Ablaufbeschreibung Mensch 


e Modul aus der Dichtigkeitsprüfvorrichtung ODER „Tray geprüft“ ent- 


nehmen 
e Endprüfung, Prüfaufkleber aufbringen, und Fertigware ablegen 


Einen Teil der Anlage zur Montage und Prüfung des Submoduls zeigt Abbil- 
dung 5.12. Im Vordergrund ist der Arbeitsplatz des Werkers und die Zone der 
Kollaboration erkennbar. Von links können vormontierte Submodule einge- 
legt und vollständig montierte und geprüfte entnommen werden, von rechts 
kann der Roboter auf den selben Bereich zugreifen. Deutlich erkennbar sind 
die vertikalen gelben Leisten der Lichtvorhänge, die für sofortigen Stillstand 
des Roboters sorgen, sobald zum Beispiel der Werker in den gemeinsam 
genutzten Arbeitsraum greift. Daraus ergibt sich auch die Feststellung, dass 
es sich im strengeren Sinne nicht um echte Kollaboration handelt, sondern 
um Synchronisation (siehe auch Unterabschnitt 2.2.1 auf Seite 22), bei der 
Werker und Roboter zwar im selben Arbeitsraum agieren, aber nicht zur 


selben Zeit. 
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A 


Abbildung 5.12: Bereich der Kollaboration im Anwendungsfall Euchner, in dem die MGB2 
Submodule zwischen Anlage und Werker ausgetauscht werden. Das Foto 
entstand während der Inbetriebnahme der Anlage. 


Die in Kapitel 4 vorgestellte Methodik wurde teilweise (siehe Tabelle 5.1) für 
diesen Anwendungsfall implementiert. Die Anlage mit ihren Komponenten 
wurde dazu in AML beschrieben und ein allgemein gehaltener Arbeitsplan 
generiert, der für alle denkbaren Varianten übergreifend gilt und im zentralen 
OPC-UA-Server bereitgestellt wird. Bei Eingang eines Auftrags aus dem 
ERP über den Manufacturing Integration Bus (Export als CSV aus SAP) wird 
der variantenbezogene Arbeitsplan generiert und die Simulation gestartet. 
Ergebnis der Simulation ist ein verfeinerter abgesicherter Arbeitsplan, der 


durch weitere Informationen wie Durchlaufzeiten angereichert ist. Bei dieser 
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Implementierung übernimmt der Manufacturing Integration Bus im Sinne 


eines minimalen MES die Steuerung über den OPC-UA-Server. 


Im Detail betrachtet werden bei dieser auf den speziellen Anwendungsfall 


der Fa. Euchner bezogenen Implementierung dabei die folgenden Schritte 


durchlaufen: 


1. 
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Beschreibung der gesamten Cobot-Zelle in AutomationML. Dabei 
können Werkzeuge wie der „Asset Configuration Manager“ aus dem 


Skillpro-Projekt zum Einsatz kommen. 


. Beschreibung der für die Montage aller Varianten erforderlichen Skills. 


. Fähigkeitsbasierte Planung auf Basis der in der beiden vorherigen 


Schritten erstellten Grundlagen. Diese Grobplanung gilt für alle Pro- 


duktvarianten. 


. Über den Manufacturing Integration Bus auf Basis der Seeburger Busi- 


ness Integration Suite wird der Arbeitsplan in einer erweiterten Version 
von CollabML auf den OPC-UA-Server übertragen. 


. Die tatsächlichen Auftragsdaten aus dem SAP/ERP werden ebenfalls 


auf den OPC-UA-Server geschrieben. 


. Auf dieser Basis kann die Simulation der Montage der speziellen 


Produktvariante beginnen, die als Ergebnis einen angereicherten, de- 
taillierteren Arbeitsplan als Ergebnis hat, der an den OPC-UA-Server 


zurückgegeben wird. 


. Die eigentliche Montage in der realen Welt kann nun unter Verwendung 


des mit Hilfe der Simulation erzeugten bzw. geprüften Arbeitsplans 
beginnen. Die aus der Simulation bekannten erwarteten Parameter wie 
z.B. Durchlaufzeiten dienen zur Kontrolle und als Referenz für die 


tatsächliche Montage. 


5.5 Zusammenfassung 


Die in diesem Anwendungsfall implementierten Teile der gesamten Methodik 


konnten an der Anlage erfolgreich validiert werden. 


5.5 Zusammenfassung 


An drei Implementierungen, die jedoch jeweils nicht alle Teile der Methodik 
beinhalteten, wurde die Methodik validiert. An einem Minimal-Demonstrator, 
der einen sehr einfachen Fall der Kollaboration abbildet, konnten insbeson- 
dere die Methoden zur Steuerung, Persistierung, Monitoring und Analyse 
erprobt werden. Dem realen Anwendungsfall unter dem Aspekt der Steue- 
rung und Simulation etwas näher war die Erprobung am Demonstrator mit 
erweitertem Funktionsumfang, bei der der Schwerpunkt auf der Simulation 
auf Basis des Digitalen Zwillings und der Anbindung aller Systeme über 
den Manufacturing Integration Bus lag. Eine Anwendung in einem mittel- 
ständischen Industrie-Unternehmen zur kollaborativen Montage eines Taster- 
Moduls diente abschließend zur erneuten Erprobung der Methode an einer 
industriellen Anlage in Inbetriebnahme. Hier lag der Schwerpunkt auf der 
Generierung der Arbeitspläne und der Kommunikation mit der Simulation 
und der Steuerung des Arbeitsablaufs über den Manufacturing Integration 
Bus. 
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6 Zusammenfassung und Ausblick 


In den vorangegangenen Kapiteln wurde eine neue Methodik für Wissens- 
und Prozessmanagement bei der interaktiven kollaborativen Montage varian- 
tenreicher Produkte vorgestellt und validiert. In diesem Kapitel wird neben 
einer Zusammenfassung (Abschnitt 6.1) ein Ausblick gegeben, welche For- 
schungslücken weiterhin bestehen und durch zukünftige Arbeiten adressiert 


werden könnten (Abschnitt 6.2). 


6.1 Zusammenfassung 


Die kollaborative Montage variantenreicher Produkte kann für Unternehmen 
ein Weg sein, den Wünschen der Kunden nach individualisierten Produkten 
ökonomisch sinnvoll zu entsprechen. Neben zahlreichen weiteren Aspekten 
wie der Sicherheit oder der geeigneten Konstruktion der Anlage entscheidet 
ein effizientes Informationsmanagement über den Erfolg solcher Montagean- 
sätze. Ziel der vorliegenden Arbeit ist daher die Entwicklung einer Methodik 
für das Wissens- und Prozessmanagement bei der interaktiven kollaborativen 
Montage und die Beantwortung der Hauptforschungsfrage FO (siehe Seite 
9). 


„Bin Cobot ist ein Roboter, der gemeinsam mit einem menschlichen Bediener 
Objekte manipuliert.“ (Colgate, Wannasuphoprasit und Peshkin 1996) Es 
gibt verschiedene Formen der Interaktion zwischen Mensch und Roboter, 


die sich durch Art und zeitliche Nutzung des gemeinsamen Arbeitsraums 


135 


6 Zusammenfassung und Ausblick 


abgrenzen lassen. Der Begriff „Kollaboration“ wird uneinheitlich verwendet, 
oft als Oberbegriff für jegliche Arbeitsweisen, an denen ein Roboter und ein 
Mensch beteiligt sind, im engeren Sinne bedeutet Kollaboration jedoch die 
gemeinsame Arbeit am selben Objekt zur selben Zeit. Aktuelle industriel- 
le Standards wie OPC UA und AutomationML bilden die Grundlage der 
Methodik. 


Zwar gibt es einige aktuelle Ansätze für das Informationsmanagement bei der 
kollaborativen Montage, es existiert jedoch noch keine Methodik zur durch- 
gehenden Konsolidierung und Rückführung aller Daten von der Planung über 


die Simulation und Ausführung und zurück ins Engineering. 


Zentraler Bestandteil der in dieser Arbeit präsentierten Methodik für das 
Informationsmanagement ist der Manufacturing Integration Bus, eine infor- 
mationstechnische Einheit mit zahlreichen Schnittstellen, die alle Aspekte 
der kollaborativen Montage unterstützen. Sowohl das Produkt als auch die 
Anlage durchlaufen einen Lebenszyklus, der durch jeweils einen Digitalen 
Zwilling modelliert und abgebildet werden kann. Dies ermöglicht auch die 
Simulation der Montage vor deren tatsächlicher Ausführung. Der Manufac- 
turing Integration Bus hält alle Daten bereit und stellt sie den beteiligten 


Systemen im geeigneten Format zur Verfügung. 


Die Steuerung der kollaborativen Zelle kann ebenfalls vom Manufacturing 
Integration Bus übernommen werden, da am Markt verfügbare MES Systeme 
nicht alle für die kollaborative Montage erforderlichen Fähigkeiten haben. 
Dabei erlaubt die Methodik eine zentrale oder eine dezentrale Steuerung, je 


nach Anwendungsfall. 


Die bei der realen Montage entstehenden Prozessdaten sind eine wertvol- 
le Quelle für weitere Optimierungen und Engineering-Zyklen. Alle in der 
kollaborativen Zelle vorhandenen Assets werden per OPC UA an den ag- 
gregierenden OPC-UA-Server angebunden, so dass die Zelle nach außen 


durch ein einziges System vollständig repräsentiert wird. An den jeweiligen 
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Anwendungsfall angepasste KPIs und deren Anzeige als Dashboard erlau- 
ben ein Echtzeit-Monitoring der Montage, insbesondere durch Vergleich 
der tatsächlichen Werte mit den Ergebnissen der Simulation. Mit Hilfe des 
ebenfalls im Rahmen dieser Arbeit entwickelten OPC-UA-Loggers können 


diese Prozessdaten in einer Datenbank persistiert werden. 


Auf Basis der über einen oder mehrere Montagedurchläufe erfassten Daten 
können verschiedene Analysen durchgeführt werden, deren Ergebnisse in 
spätere Engineering-Schritte einfließen. Dabei ist die durch die Modellierung 
von Produkt und Anlage bekannte Struktur das wesentliche Kriterium für 


den Mehrwert der Analyse. 


Die Methodik wird an drei verschiedenen Fallbeispielen validiert, einem 
Minimal-Demonstrator, einem Demonstrator mit erweitertem Funktionsum- 
fang und einer industriellen Anlage in Inbetriebnahme. Dabei erweist sich in 
allen drei Fällen die Eignung der Methodik für das Informationsmanagement 


bei der kollaborativen Montage. 


6.2 Ausblick 


Trotz gewisser Chancen zeigen sich in der Praxis auch Nachteile der kolla- 
borativen Montage, zum Beispiel die aus Sicherheitsgründen sehr langsame 
Bewegung und dadurch herabgesetzte Durchlaufzeit mit ihren ökonomischen 
Folgen. Hier könnten erweiterte Ansätze untersucht werden, zum Beispiel 
die weitere Aufteilung der Arbeitszonen mit schnelleren Roboterbewegun- 
gen in Bereichen, in denen sich kein Mensch aufhält. Auch die dynamische 
Erkennung der Bewegungen des Menschen und die Reaktion der Anlage 
darauf könnte weitere wirtschaftliche Vorteile bieten. Diese Ansätze müssten 
von einem weiterentwickelten Informationsmanagement unterstützt werden. 


Kritische Stimmen gelangen aufgrund dieser und weiterer Einschränkungen 
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sogar dazu, dass die kollaborative Montage vermieden werden sollte (Herfs 
u.a. 2019, S. 99). 


Auch die tiefergehende Untersuchung der Möglichkeiten, die die Echtzeit- 
Simulation, also die gleichzeitige virtuelle und reale Ausführung der Montage, 
bieten kann, verspricht eine weitere Optimierung, besonders wenn ihre Er- 
gebnisse zur Echtzeit-Umplanung zum Beispiel beim Eintreffen unvorherseh- 
barer Hindernisse genutzt werden könnte. Die Schnittstelle zwischen Mensch 
und Maschine und ihre Unterstützung durch ein erweitertes Informationsma- 
nagement könnte ebenfalls Gegenstand zukünftiger Forschungsansätze sein, 
auch unter Berücksichtigung alternativer Bedienkonzepte wie der Sprach- 
oder Gestensteuerung oder der Anzeige von Informationen in verschiedenen 
Sprachen und Komplexitätsgraden angepasst an die individuellen Fähigkeiten 


des jeweiligen Werkers. 


Ein voraussichtlich mit der Zeit erheblich steigendes Datenvolumen der Pro- 
zessdaten könnte weitere Forschung auf dem Gebiet der Anwendung des 
Datastream Processings erforderlich machen. Auch fortgeschrittene Analyse- 
möglichkeiten unter Einbeziehung moderner Ansätze (z. B. Process Mining) 


könnte weitere Einblicke und Nutzen aus den Prozessdaten erlauben. 
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A Anhang 


A.1 Vergrößerte grafische Darstellungen 


In diesem Anhang werden einige Abbildungen rotiert vergrößert wiedergege- 
ben, die aufgrund des Formats im Fließtext nicht optimal dargestellt werden 
konnten. Zur größeren Darstellung wurden die Abbildungen im Querformat 


um 90 Grad gegen den Uhrzeigersinn rotiert. 
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Abbildung A.1: Beziehung zwischen den Lebenszyklen von Produkt und Produktionsanlage 


(Herfs, Storms, Roggendorf, Petrovic, Schubert, Schneider, Erkayhan, Rückert, 


Tracht und Heinen 2019, S. 55). 
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Abbildung A.2: Die KoKoMo-Methode: Workflow von der Bestellung zum finalen Produkt nach 


Herfs, Storms, Roggendorf, Petrovic, Schubert, Schneider, Erkayhan, Rückert, 


Tracht und Heinen 2019, S. 57. 
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Abbildung A.3: Übersicht zur Rolle des Manufacturing Integration Bus im Kontext der gesam- 


ten Methodik. 
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Abbildung A.4: Datenfluss zur Persistierung von Prozessdaten mit angeschlossenem Monito- 
ring und Analyse auf Basis von OPC UA. 
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Abbildung A.5: Gesamtüberblick über den Fischertechnik Minimal-Demonstrator zur Veran- 
schaulichung kollaborativer Montage. 
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Abbildung A.6: Ansicht des am Werkzeugmaschinenlabor der RWTH Aachen aufgebauten 
KoKoMo Demonstrators. Foto: Simon Roggendorf (WZL RWTH Aachen). 
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Abbildung A.7: Systemarchitektur zur Steuerung und Rückmeldung von Prozessdaten am De- 


monstrator mit erweitertem Funktionsumfang. Abbildung: Simon Roggendorf 


(WZL RWTH Aachen) 
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A.2 CollabML 


Die folgende Definition und das zugehörige Beispiel stellen eine auf die 


wesentlichen Elemente vereinfachte Variante von CollabML dar, die in der 


Anwendung um weitere Informationen angereichert werden kann. 


A.2.1 Definition (XSD) 


<xs:simpleType 


SES 


<xs: 


<xs: 


<xs: 


<xs: 


<xs:schema attributeFormDefault="unqualified" 
— elementFormDefault="qualified" xmlns:xs="http:// 
— www.w3.org/2001/XMLSchema"> 


name="integerlist"> 


<xs:list itemType="xs:integer"/> 
</xs:simpleType> 
<xs:element name="AssemblyOrder"> 
<xs:complexType> 
<xs:sequence> 
<xs:element type="xs:integer" name="id"/> 
<xs:element type="xs:integer" name="productId"/> 
<xs:element name="task" maxOccurs="unbounded" 
— minOccurs="0"> 
<xs:complexType> 


<xs:sequence> 


element type="xs:integer" name="id"/> 
element name="waitForTasks" type=" 

=> integerlist"/> 

element type="xs:string" name="name"/> 
element type="xs:integer" name=" 
— defaultResource"/> 


element name="resources"> 


<xs:complexType> 
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<xs:sequence> 
<xs:element name="resource" maxOccurs=" 
— unbounded" minOccurs="0"> 
<xs:complexType> 
<xs : Sequence> 
<xs:element type="xs: integer" name 
— ="id"/> 
<xs:element type="xs:string" name 
— ="name"/> 
<xs:element type="xs:string" name 
— ="taskDescription"/> 
</xs:sequence> 
</xs:complexType> 
</xs:element> 
</xs:sequence> 
</xs:complexType> 
</xs:element> 
</xs:sequence> 
</xs:complexType> 
</xs:element> 
</xs :sequence> 
</xs:complexType> 
</xs:element> 


</xs:schema> 
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A.2.2 Beispiel (XML) 


<AssemblyOrder> 
<id>8653</id> 
<productId>34</productId> 
<task> 
<id>1</id> 
<waitForTasks/> 
<name>Pick & Place part 378</name> 
<defaultResource>2</defaultResource> 
<resources> 
<resource> 
<id>1</id> 
<name>Worker</name> 
<taskDescription>task86432worker.xml</ 
— taskDescription> 
</resource> 
<resource> 
<id>2</id> 
<name>Cobot 1</name> 
<taskDescription>task86432cobot .xml</ 
— taskDescription> 
</resource> 
</resources> 
</task> 
<task> 
<id>2</id> 
<waitForTasks/> 
<name>Pick & Place part 385</name> 
<defaultResource>2</defaultResource> 


<resources> 
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<resource> 
<id>1</id> 
<name>Worker</name> 
<taskDescription>task86435worker . xml</ 
— taskDescription> 
</resource> 
<resource> 
<id>2</id> 
<name>Cobot 1</name> 
<taskDescription>task86435cobot .xml</ 
= taskDescription> 
</resource> 
</resources> 
</task> 
<task> 
<id>3</id> 
<waitForTasks>1 2</waitForTasks> 
<name>Assemble parts 378 and 385</name> 
<defaultResource>1</defaultResource> 
<resources> 
<resource> 
<id>1</id> 
<name>Worker</name> 
<taskDescription>task86439worker . xml</ 
— taskDescription> 
</resource> 
</resources> 
</task> 
<task> 
<id>4</id> 


<waitForTasks>3</waitForTasks> 
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<name>Move assembly</name> 
<defaultResource>2</defaultResource> 
<resources> 
<resource> 
<id>1</id> 
<name>Worker</name> 
<taskDescription>task86481worker.xml</ 
— taskDescription> 
</resource> 
<resource> 
<id>2</id> 
<name>Cobot 1</name> 
<taskDescription>task86481cobot .xml</ 
— taskDescription> 
</resource> 
</resources> 
</task> 
</AssemblyOrder> 
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